ARIN XXV Public Policy Meeting Draft Transcript - 20 April 2010
"This transcript of the meeting may contain errors due to errors in transcription or in formatting it for posting. Therefore, the material is presented only to assist you, and is not an authoritative representation of discussion at the meeting."
Table of Contents
- Meeting Called to Order
- Policy Development Process
- Law Enforcement Agencies and ARIN
- POC Validation
- Draft Policy 2010-3: Customer Confidentiality
- Draft Policy 2010-6: Simplified M&A transfer policy
- Regional PDP Report
- Internet Number Resource Status Report
- Best Current Practices
- BGP in 2009
- Effects of new prefixes on inter and intra-domain routing scalability
- Draft Policy 2010-2: /24 End User Minimum Assignment Unit
- Draft Policy 2010-5: Reduce and Simplify IPv4 Initial Allocations
- Upcoming Services - DNSSEC and RPKI
- New ARIN Online Features
- RIR Update - AFRINIC
- RIR Update - APNIC
- ITU Update
- Open Microphone
- Closing Announcements and Adjournment
John Curran: Good morning and welcome. Welcome to the ARIN XXV meeting, this is our 25th ARIN meeting, in Toronto, and I'd like to thank everyone for making it here.
We actually had great success getting everyone here. We did have a few folks who couldn't make it who were traveling from overseas. But luckily almost everyone managed to find a routing that worked.
Okay. I'd like to start out with some announcements. First of all, we have the Board of Trustees here. John Curran, as president and CEO I sit on the Board. Paul Andersen. Where are you, Paul? Scott Bradner. Timothy Denton is right there. Lee Howard, right there. Paul Vixie, our Chairman, and Bill Woodcock, who is hiding in back.
We have the numbers of our Advisory Council present. I could read them all off, but I'll just say AC members. Why don't you stand up for a moment. Several of them up on stage, including John Sweeting, our Chair, and then the rest of them are out in the audience right now. These are the folks who work on the policy. If you have a question about a policy or a draft policy, and you would like to discuss it with someone knowledgeable, seek out one of these folks. If you have an idea for change to policy you'd like to have submitted, seek out these folks. They can walk you through the process, explain some of the things you need to watch out for.
We have members of the NRO Number Council. The Number Council works with the other RIRs to work on global policies as part of the ICANN function. We have Martin Hannigan. I know Martin's here. Marty? Nope. We'll see him shortly. Louis Lee. Where are you, Louis? And Jason Schiller. All three of these people I've seen in the last 12 hours. Maybe they're having the secret NRO Number Council meeting. The NRO Number Council are the ones that work with other RIRs, the other regions, and get together and work on global policy. They serve as a portion of the address supporting organization in the ICANN function. So they're the ones that validate that the policy process has been followed for global policies and sends them to the ICANN board for ratification.
Our RIR colleagues. We may not have all of these folks. Adiel, are you here? Runs AFRINIC. From the RIPE NCC, this is where we tended to lose a few folks. If you're here from RIPE and made it, stand up. LACNIC, I know we have some LACNIC attendees. Sergio and Raul, and I believe Alejandro is here. APNIC. Anyone from APNIC? Yes. All right. Geoff. Geoff Huston. And did we have Adam make it? Quite a few of our RIR colleagues attend, that's because we try to use a similar framework for establishing number resource policy. It's good for us to know what's happening in each of the regions.
The ARIN management team is here. Susan Hamlin, probably off -- that's right, working on arrangements. Mark Kosters. Mark. I don't know where Mark is. Mary K. is in back. Thank you, Mary K. Leslie Nobile, Registration Services. Bob Stratton, our finance person. Myself, obviously. Nate Davis, Chief Operating Officer. Nate's -- he just walked by. Nate's here as well, making arrangements certainly for the meeting. Cathy Handley, our Executive Director of Government Affairs. And Richard Jimmerson, our CIO.
So I also want to say we have a fellowship program, and these fellowship recipients receive their expenses and fee waivers so they can attend ARIN and bring a message about Internet registry services back to the other regions. So from Canada, Steve Bertrand. Steve. Very nice, Steve. From USA, Chris Meisl. Chris. And from the Caribbean, Evona Channer. Very good. We try to make sure that the fellowship program allows us to introduce new blood to ARIN, get people in other regions involved. One of the key parts of the selection criteria is ability to take the policy discussions and the messages from the meeting back and help disseminate those in the respective sub-sectors of ARIN.
So first timers, I know we have a number of first timers. I met a lot of them yesterday at our First Timers’ Luncheon. They got a chance to meet and have discussions with the ARIN staff, members of the Board, and AC. And we had a little survey. As a result of the survey we had a prize drawing. I actually had all the survey results. All the positive ones. No, actually all the survey results.
And I will ask for a volunteer from the audience. Mr. Bill Darte, why don't you come on up. And the surprise drawing for those who completed the survey for a $100 gift certificate. Go ahead. Dig in there. Perfect. Okay. The winner is...
Unidentified Speaker: Bill Darte.
John Curran: Adam Gosling. Where are you, Adam? Congratulations.
Adam Gosling: I'll donate mine back. Thank you.
John Curran: We'll pass. Okay. Come on back, Bill. I'm going to mix these up. Justin Caissie of Carat Networks. Justin, are you here? Congratulations. We'll get you the certificate. You're all set.
Moving right along. Press. ARIN has invited members of the local press and IT media to attend the ARIN meeting. We had press requests, and we have an open meeting. So, of course, they're welcome. They wear clearly identifiable badges. Do we have any members of the press in the audience right now? I'd have them stand up. But, remember, we treat these folks with respect. No target practice.
But the members of the press have strict press policy. You can actually see it on the ARIN website. Comments made in the meeting, while they may be used for background, are not for attribution. If someone wants to directly quote you, then they will come up and ask your permission. You'll have a chance to have a discussion with them. There are members of the press present. It's possible someone will try to characterize the discussion going on here, but you will not be directly quoted without being approached and being asked for permission.
Surveys. Okay. We have surveys every day. Submit your surveys somewhere between 8:00 a.m. and 6:00 p.m. We do use these to refine the meetings. And we do prize drawings each morning. There are some great prizes. They get better and better every year.
Remote participants. I know we have a number of remote participants. You're also welcome to participate in the survey. And today's survey topic is social media, how social media is used and how ARIN should use it. So we definitely ask you to participate if you get a chance, particularly you remote participants.
Daily survey. So it's time to announce our winner. Didn't we have a survey yesterday? No, we have must skipped this. I don't think we had a survey. But tomorrow the Freeloader Pico solar charger will be given out to the survey recipient.
Remote participants. People should know we have remote participants at ARIN meetings. It's very important. They have access to the webcast of the actual session and they have a live transcript they can follow. There's a chat room which has a virtual microphone which allows them to actually ask a question and have it read. We have an able-bodied person up here to be the remote participant person. So that they have equal time, the same opportunity as everyone else has. And they actually get to show hands during a count of the room, if we have a show of hands they can participate in that as well. All the materials for the meeting are put online. So while not everyone can be here, sometimes circumstances, travel, weather don't allow someone to participate directly in the meeting, we hope the remote participation is more than sufficient. We hope to give them an experience that's as good or corresponding to actually being here participant’s packet.
You all have a participant's folder. I know they're out there somewhere. It has the meeting program. That's an important document. It also has the Policy Discussion Guide and the Policy Development Process. These are two important things. The Policy Discussion Guide includes all of the policies that we'll be discussing at the meeting. So you don't need to go flipping online or looking around; they're all published in your packet. And the Policy Development Process, if you want to know how we develop the process, that's also there. You have a copy of the current Number Resource Policy Manual, the NRPM. This is the current policies that we use for number assignment and allocation. Sometimes it's useful to have a reference, not just the policy under consideration but the present policy. You have it in your packet. And then the invitation and instructions for the daily meeting survey are also included.
Attendance stats. We have great attendance for the meeting. We have 63 registered attendees from Canada, 91 participants from the United States, four from the Caribbean, 21 from outside the ARIN region. And we have 48 remote participants, which I'm particularly proud of. As I said, not everyone can make it to these meetings.
This should give us a good and lively discussion of the policy proposals. If you need help, if you work with ARIN and you're an ARIN member and you need help working with us, with Registration Services, you have an opportunity to do that at the ARIN meeting in the grand foyer. There's a help desk, and you can actually swing by or schedule an appointment. See your program for how to schedule an appointment with them. Also the help desk hours are there. Today it's 8:30 to 5:30, as is Tuesday, and Wednesday 8:30 to noon. We also have the ability to -- if you need to work with Financial Services, there's an e-mail in your program. You can send them to talk to Financial Services help desk.
Tonight -- tonight when we're done with discussing all these wonderful policy proposals and some of the presentations, we will have a social. And tonight's social is at the Academy of Spherical Arts, which I have to admit I had to go online to see exactly what we're talking about. It's billiards, folks, and it's an institution dedicated to billiards and pool. It will be from 6:00 to 10:30 p.m. There will be scotch tasting, a jazz trio, food, and lots more. Buses will load off the lobby at 5:45 and we'll have shuttle services running back from 7:00 to 10:30 for people who want to come back to the hotel.
Okay. Sponsors. This meeting does not happen without sponsors. And it's essential for our success. Network connectivity is provided by TELUS and equipment is provided by EGATE. Big round of applause.
And anytime if people aren't sure what the sponsors actually contribute, let me know, I'll turn off the network, and you can get a firsthand appreciation for that.
Rules and reminders. I chair the meeting, I moderate discussions of the draft policies so all can speak and all can be heard. Please state your name and affiliation each time you're recognized at the microphone. Remember, we have remote participants here. It's important to find a microphone, speak clearly, speak your name and your affiliation. Okay. It's very important. There's a list of rules and courtesies in your program. Please adhere to them.
I ask, in particular, that people speak -- when they speak on a policy proposal, try to identify up front whether you're in favor or opposed. That's something people want to know. They also want to know any other point you're going to make, but if you're in particular in favor or opposed, let's start out with that so we understand the context.
Additionally, if you see a lot of people at the microphone, please don't go up and speak a second time until you see that we have gotten everyone to speak once. It's very important that everyone at least have a chance to speak, so I ask that people not attempt to speak a second time on a topic until they've seen that everyone's had at least one chance. This is just a courtesy everyone should pay attention to.
Today's agenda, in addition to the policy discussions, we have the regional Policy Development Process Report and we have the Internet Number Resource Status Report, which will be taking place during the day.
We try to move those sessions to make sure that the actual policy discussions start where they are in the printed program. Again, that's because remote participants sometimes have an interest in only one policy discussion. We want to make sure those stay to the printed agenda as much as possible.
Today's policy discussions. Two very simple policies should have no discussion at all maybe. Draft Policy 2010-3: Customer Confidentiality. Actually, I imagine there will be quite a bit of discussion for this one. And Draft Policy 2010-6: Simplified M&A Transfer Policy. We'll have these two discussions and we'll arrange the agenda to make sure we have enough time as necessary.
We also have 2010-2, the /24 End User Minimum Assignment Unit, and Draft Policy 2010-5: Reduce and Simplify IPv4 Initial Allocations. Again, these draft policies are actually in your agenda if you want to look at them.
At the head table -- you've already met these folks, but I just want to -- at the head table we have Cathy, Paul, John Sweeting, Paul, Scott Bradner, Dan, and Marla at the end. These folks will help think about these topics as they come up. Sometimes they help me catch points that I miss. Sometimes they'll ask questions to help facilitate the discussion on interesting aspects that may need to be discussed by the community. So I'd like to start right ahead.
First item on the agenda is Policy Development Process Report. People may not know it, but we have been working on the PDP. I'd like to invite Lee Howard and John Sweeting up to give a brief report on the Policy Development Process.
Lee Howard: My name is Lee Howard, member of the Board of Trustees. As you know, we have a policy development process. That's good. Hopefully many of you were here yesterday for the introduction to the Policy Development Process that we currently have and for the Open Policy Hour discussion of potential future policies. There was not a whole lot of conversation, so we must be doing something right.
The Board has noticed that we have had this particular version of the Policy Development Process in place for a little over a year. And we have we have, in fact, developed some policies and seen some proposals we have not adopted. Erin, do you have slides for me? Sorry about that. So the Board decided that we ought to have a committee to take a look at the Policy Development Process and see if there are changes that need to be made. So the Board went ahead and named a Policy Development committee.
This is not a committee for developing policies. Just to be clear. This is a committee to look at the Policy Development Process. But we wanted to have fewer words in the name of the committee. So we went ahead -- go ahead to the next slide -- the members of that committee are me as the chair of the committee, which is why I'm talking right now. John Curran, who as president and CEO is an ex-officio member of essentially all board committees. And we have Scott Bradner, who has been a long policy development process wonk. We have Paul Andersen on our committee, as well as John Sweeting from -- as chair to the Advisory Council, and Dan Alexander as another member of the Advisory Council.
This is something different than past iterations to the Policy Development Process because we were trying to be very inclusive of our friends in the Advisory Council and, again -- and, of course, the community here. So -- go ahead. So we'll be looking for more feedback.
Specifically we've chartered to -- the charter as written by the Board is the Policy Development Committee shall make recommendations to the Board to improve the policy development process and procedures, to make it clear to newcomers what the process is, to encourage open community participation, and to strive for both timeliness and relevance in new policy.
These seem like laudable things for the process to do, and that should not be a shock to anybody. Go ahead. Thanks. The goals of the policy development process are policies, obviously, that are necessary for a significant portion of the community, that are concise and clear, and that are relevant to what it is we do: allocation and assignment of number resources.
In scope for us, these are some things that we specifically talked about as being things the committee may discuss. So we will probably look at a revised policy development process to eliminate ambiguities that people have raised to us as we gained experience with this process.
We may discuss the Global Policy Development Process as it's executed within the ARIN region. That would be in scope for discussion. Because it's part -- because the Global Policy Development Process uses the Regional Policy Development Process for finding consensus within our region.
And, finally, the committee may take up this question of who is this community. It's probably more than the people who are in the room, either physically or logically, but so who else besides subscribers to the PPML list are members of the community that we need to pay attention to. All very interesting questions and these are things that we've already discussed as being in scope forward.
So what? Why am I here telling you about this committee, the Board does not always inform the community of every little committee that we stand up. In this case we are specifically looking for suggestions. We're looking for what kinds of things have you noticed as we've been doing policy development that could be improved, either any of the things I've just discussed, clarity, relevance, timeliness, all the kinds of things that go into this process.
If you have comments, you can find any of us here at the meeting or you can send us e-mail. I've again listed the names of the people who are on this committee and given you the URLs for where you can find our e-mail addresses so that you can send us e-mail saying here's what I think. You probably don't need to e-mail every one of us, any one of us will do. We're all quite capable of speaking during our meetings.
So go to last slide. I would be delighted to answer questions.
John Curran: The floor is open. The floor is open for questions. That includes remote participants. Any questions on this committee? Okay. Thank you, Lee.
John Curran: Okay. Next up on the agenda, because we have a policy that addresses customer confidentiality and it has some implications to how some communities work with ARIN, including the law enforcement community, I was asked whether or not we could make some time on the agenda to have a brief presentation from some members of the law enforcement community regarding how they work with ARIN and use our databases in getting their job done. So at this time I'd like to ask Bobby Flaim and Marc Moreau to come on up for the presentation.
Marc Moreau: It's good to be recognized, I guess. And welcome, everybody, to Canada. I'm Marc Moreau. I'm with the RMCP. And Bobby Flaim, I'll let him introduce himself. I think a lot of people have seen him already.
Bobby Flaim: Bobby Flaim, FBI Operational Technology Division based in Quantico, Virginia.
Marc Moreau: The reason we wanted to drop in and speak with you today is to open the dialogue. I think it's important that we have a chance to speak to different people in the community, and we have a chance to do that actually with the help of Leslie here and Cathy, with the ARIN Government Working Group. One of the things we'd like to do here is --
Bobby Flaim: Like Marc said, the main reasons we're here, we wanted to let you know some of the things we've done not only within ARIN but the greater community and why it's so important that we all work with you and why you are important to us and why everything that ARIN does and a lot of the Internet governance organizations are critical to what we do. And the goal of this presentation is to let you know some of the things we do and just to, like Marc said, start a dialogue. The customer confidentiality that was just one very small piece that obviously caught our attention because it will have a direct impact on what we do.
So like the slide says, there are a lot of things that we're doing; we just don't come to ARIN. We've worked with all of the different regional Internet registries, as you see, ARIN, AFRINIC, LACNIC, through our respective partners in those regions. We work with the Nigerian police, the Brazilian police, the Japanese police, the Australian police, and the New Zealand police. I don't want anyone in the community -- I realize there's 21 non-ARIN members here -- to think that it's just in this region. We really are trying to become better stewards, become more aware of actually what goes on within these Internet governance bodies and actually speak with you, work with you, because I think really we're all after the same thing, which is the security and stability of the Internet.
We really just want to find out people who are doing nefarious things, capture them, and stop them. And really we actually want to prevent them from even committing these acts before they start. So as you can see there, we've worked with a lot of different Internet governance organizations. We've worked with a lot of different police organizations. And we're not only working within the IP community, we're working at DNS. We've actually introduced a law enforcement proposal within ICANN, the Internet Corporation of Assigned Names and Numbers, to pretty much accomplish what a lot of the other organizations and businesses and registries, good registries, registrars have proposed already, which is to have good data to make sure criminals don't have access to this. And if they do, we know where to find them and how to stop them.
What we've done in that respect, we've actually started to create with the regional Internet registries what is called these government working groups. What the government working groups are -- we have one here in ARIN; we started it last year in February -- is where we would have government agencies, law enforcement agencies, regulatory agencies such as the FBI, RCMP, Industry Canada, Department of Commerce, FTC, and also private companies. We've had Google come and VeriSign and Comcast, and we're trying to make that even more inclusive. And the reason for that, again, is to develop these groups where we can talk to each other. A lot of times government really hasn't been coming to these meetings, or, if they do, they're not quite sure how everything works: the policy proposal, the fact that it's a bottom-up consensus-based organization, and everyone works together.
And one of the main goals of the working groups is actually try to educate government, to make sure that they know exactly what's going on and if there's equities that they need to be made aware of, then they can be made aware of them. If there's policies they like or don't like, then they need to speak up and they need to be part of the process, and that is the main goal of these working groups.
We have one in ARIN. AFRINIC, I see Adiel in the audience. He started his first government working group this January in Mauritius. LACNIC started one last May. They're going to have another one. I see Raul here. APNIC, I think they're still in the process. RIPE has one. RIPE NCC, Paul Rendek. We've had SOCA. We've had the Dutch police involved in that one. And they've been very, very good.
As you see there we're getting a little bit ahead of the horse here, but we have customer confidentiality there. And we'll go into why it's important for us as law enforcement that the WHOIS database are among one of the many tools that we use and why it's important to us, as you can imagine.
Things such as the customer confidentiality, we won't go into it too much here because there's going to be discussion, but obviously anytime we don't have access to the WHOIS database, it has a negative impact, because it slows down investigations measurably. We'll talk a little bit to that there. But so Marc can actually start talking. I'll shut up.
Marc Moreau: Just to reassure everybody. As this slide says, we're not Big Brother. I think there's a lot of fear out there oftentimes that people think, well, this is the government and we have to know everything and you have to work with us. And that's not where we're coming from here. Again, going back to one of the main reasons why we're here today is to engage and have those conversations. We want to open up that dialogue. I saw the first slide and it said there were how many people from Canada, 63, I think it was.
Whether it's in Canada or the U.S., or any country for that matter, one of the questions I would ask anybody here is would you know who to contact if something happened on your networks, for example? Would you automatically know this is the person that I need to contact? If you don't have the answer to that, then that tells you that you need to have more dialogue. You need to have that conversation. Trying to find out exactly where to go when the time is needed.
In Canada here, just to give you a quick -- just going off the slide a little bit -- we have 14 field units across Canada. That covers all the major centers across Canada. We're not as big as the States, obviously. But I would encourage you to, for some of the people that are here from Canada, for example, and also from the States, reach out and talk to those people. I think we have probably a few people, quite a few people actually from law enforcement. If you don't mind -- I don't want to put you on the spot, but if you want and can identify yourself, could you put your hand up from law enforcement. There's some in the corner over here. One way in the back. All in the back. We just take the corners and in the back.
John Curran: We'll put more lighting back there.
Marc Moreau: But I would encourage you to have a dialogue with those people so that you find out -- I think it's very important we need to know more about what you do, what makes you tick, your community. And I think the same applies for yourselves as well. You need to know a lot more about how we do it, what we do, for example, our daily work. It's very important, because as we get to work together and we have that dialogue, then we can start working against the criminals. And this is always very important.
So as Bobby already mentioned, like he said, we really want to work with ARIN and a lot of organizations as well, and our goal is simple. Really to have safer homes, safer communities and to make the Internet as safe as we possibly can; that's a major undertaking, no doubt.
The IP WHOIS, as Bobby touched on it before, it's really a tool that we use. It's not the only tool. We understand that there's obviously a lot of bad information that is out there. Somebody that's registered as Donald Duck kind of raises the flag even for us. So we understand that part.
But I think, again, if we worked closer together, both our communities and your communities, to clean up some of the stuff that is actually registered, but it is sometimes a lead. And the lead is very, very important. It takes us a long time, those types of investigations. They happen at the snap of a finger where they actually go from one country to the next, very easy to do.
And contrary to what you see on TV, the CSI movies or -- you know, we don't solve crime in an hour. It takes much longer than that. And also if we have to deal with some of the other countries, there are some legal processes that we have to use. It is cumbersome at times, but it can be done. But those are some of the issues that we have. IP, the WHOIS, for example, is only one tool. But it's something that is near and dear to our hearts, for example, and we'd like to keep that.
The due diligence, Bobby touched on that as well. We did put some recommendations, the law enforcement group did, to ICANN and its making its way through quite -- well, different organizations that it's gone through the COE, the cyber crime council. It's also gone through INTERPOL, I believe it is, and now will make its way back to ICANN. We've had the support of the GAC from the ICANN as well. So I think it's a clear example of some of the good things that are happening with law enforcement and working with your community as well. Very important.
And also by attending these types of meetings and ICANN as well, it affords us to keep in tune with your community. Some of the pressing issues, some of the challenges that you're facing, and hopefully we can work together to try to meet those challenges in the future as well.
Bobby Flaim: One of the things that Marc was just talking about in his last slide, emerging technologies. We had actually an initiative within the FBI; it's called Going Dark, which is where we are trying to make sure that as good stewards, as law enforcement, as the protectors of the public that we're fully aware of all the emerging technologies that are out there.
As you know, being government agencies, even the FBI, which is a very big agency, obviously, and has a larger budget than most, there still is the problem that we are losing our ability to do actual lawful interceptions. It's not just being able to turn on a switch for anything and everything we want. Because we're dealing with very complex issues, very complex technologies, wireless, IPv6 is coming in, we have internationalized domain names are coming in. Skype, you name it. Whatever is out there, and it continues to change daily, almost hourly. There is like a serious concern on our part that we are actually losing ground and that we may not actually be able to do the job in which we are assigned to do, which is lawful interceptions by legal court orders.
So this is another reason why we're here. It's not just to talk about policies but also to talk with you to make sure we're fully aware of everything that's going on. We have a list there of some of the tools that we use. And these are obviously very, very basic tools. And what we use them for is basically triage, the first wave or the first line of an investigation.
And a lot of times you're saying why are these important? This is ridiculous. Do you really depend on the IP WHOIS and Google and so on and so forth? Well, the key to these particular tools and the fact that they're very basic and very public is the fact that a lot of times when you have to go to a prosecutor and you actually have to start your investigation, if you actually can't get these rudimentary pieces of evidence, even though they may be imperfect or incomplete, at least they are a start.
I think that is what a lot of people fail to realize, because if you need a subpoena and court order for every little piece of investigation, your investigation never actually gets started. If your investigation stops before it gets started, this is where you're losing very critical pieces of information and the fact that you actually can't do your investigation.
Another thing that is actually very important is that although I'm in the United States and I can deal with ARIN and a lot of the ISPs, we actually have a lot of foreign law enforcement counterparts. Take Marc, for instance. If he has an investigation that deals with an American company or American ISP, if these aren't publicly available databases where at least he can start his investigation, what he'd have to do is he'd have to go to his prosecutor, which in turn would have to go to his Department of Justice, which in turn would have to go to your our Department of Justice, which in turn goes to our prosecutor, which in turn goes to us.
I mean, as hard and painful as it sounds, it really is. It will take months if not years and unless it's something so imminent and the president or a very high executive officer is involved in, that kills an investigation. So the reason why these are important, not only because for us domestically, they would start an investigation, but since the nature of cyber crime and all crimes, really, are so important, it really depends on other foreign law enforcement actually having access to these public tools such as Google, such as domain, IP WHOIS and so on and so forth what you see there.
So there's also a method to this simplicity as well. The WHOIS, we've beaten that to death, but we'll beat it some more. But obviously we need that. And you wanted to talk about the first two parts? Obviously it's an integral tool. And the other thing I did leave out is the speed and accuracy in getting the data is key. We actually had a policy proposal, I think it was in San Antonio, where ARIN was going to validate the points of contact, and they said if the person didn't respond, they were going to take that information out. We said no; please keep it in because at least it's a scintilla of evidence. It's a place for us to start.
As crazy as that might sound, but sometimes bad information is still information. It's kind of like publicity. No such thing as bad publicity. Any publicity is good. It's kind of the same concept. As I mentioned before, legal process, a properly maintained WHOIS actually speeds up an investigation. So the fact that we not only use it and there may be bad information, obviously we want good information, because that actually makes our job easier. Some of the problems that we have are if we look into the WHOIS and we see it may be assigned to Comcast but Comcast assigns it to level 3 and then so on and forth, it becomes very difficult and cumbersome to actually go through each one of those assignments and each one of those ISPs. So that's why it's critical that we're able to tell where that IP address goes to and who to contact. When I say who to contact, it's for legal process, to make sure that we are directing our prosecutor, our subpoenas, and our legal court orders to the right place.
Obviously just some examples. 9/11. This is actually getting old now. But still very important. 9/11. Another big thing is kidnappings. We use it -- these are the very traditional crimes. This isn't only cyber crimes. That's the purpose of this. There are still a lot of traditional crimes we rely on. Child pornography, also something very big, constantly ongoing. You think it's going away. It's almost like shooting fish in a barrel, but it's still very pervasive. Intellectual property crimes, botnets, farming, phishing, all of these things are things that we're obviously investigating and things that we actually use the WHOIS for. And do you have anything?
Marc Moreau: The only thing I would add to what Bobby was talking about, with regard to investigations, Bobby was mentioning, for example, if something happened in the States and there's a request for Canada to do an investigation, there is a process, what they call MLAT, the Mutual Legal Assistance Treaty. But it takes months and sometimes up to a year to get that process moving.
So oftentimes what we try to do is whatever investigation that may occur in another country, if we can start our own parallel investigation in our own country, which expedites that whole investigative process, for example. So there are ways we can do it. Again, I'm just throwing it out there for you so that if you have any questions -- again, I go back to what I said before -- I think it's very important you reach out.
You can ask me after the presentation. For those from Canada, I can point you in the right direction, for example, to our field units, and also the municipal police forces as well. We work a lot with our police services here in Canada. There's what we call the National Tech Crime Advisory Committee, and that regroups all of the actual major centers that have a high-tech crime unit. And we meet on a regular basis to discuss some of the challenges that we have even here across Canada.
So, again, I would just encourage and promote that hopefully that you will reach out to the corners, at least in this room here and maybe in some of the future rooms, but talk to your local law enforcement just so you can find out exactly what are their challenges or what are some of the things they need as part of investigation.
John Curran: Thank you for the informative presentation. Microphones are open for questions. I'd like to avoid discussing specific policy proposals since those all have a slot on the agenda already. Okay. Center microphone.
Aaron Hughes: Good morning. Aaron Hughes, 6connect. I find that frequently when receiving subpoenas for abuse purposes there are a lot of agencies out there that today don't know WHOIS tools exist. And as a service provider we may be having an assignment to another service provider with a sub-assignment, and they start along this process of asking for a subpoena for the information, where they get a subpoena from the sub-client and then a subpoena for the client of the client.
And I often spend time educating them to make sure that they know how to find this data. It would be nice to have a centralized place we can refer those agents for your own internal programs to help educate them. Is there something like that that exists today that we can refer them to?
Marc Moreau: In the States, in Canada, or both?
Aaron Hughes: Globally. But primarily from the States.
Bobby Flaim: There isn't at this time. I understand the frustration. We've actually talked about creating a centralized telephone or mechanism. We do have the Internet Crime and Complaint Center, but that really isn't for that. So what you're really referring to is somewhere that an agent can call up.
Aaron Hughes: Similarly, for an internal training process so it's not an endless battle; that we can help in a much more constructive way.
Bobby Flaim: Right. That's definitely one of the things we've recommended in the past and we continue to. Unfortunately, since there are 18,000 law enforcement agencies within the U.S., it gets complicated. Even within -- I'll speak from the FBI's perspective. We have 56 field offices within the United States. But that -- it is a very valid point. It's good.
And a lot of times there's a discrepancy. I don't want to say in the training, but in the individual agents, which, unfortunately, I don't know if we're ever going to solve. But you're correct. And we need to do it. We need to do it. So thank you and we'll try.
Aaron Hughes: Thank you, guys.
John Curran: One follow-up on that. Leslie, we do training for law enforcement on occasion, actually train trainers to help train law enforcement. So we train LEA trainers. Are those presentation materials online?
Leslie Nobile: No.
John Curran: But there's no reason they couldn't be. So we could take the materials that we use to train trainers and put them on the website in a particular URL that you could use when you're responding if they wanted to self-educate. Would that be helpful? Okay. Leslie, can you --
Leslie Nobile: Absolutely.
Bobby Flaim: What we actually did, just to follow up on John's point, we've actually had ARIN come out to train our field investigators at the FBI. I know she's gone to the Army. Who else have you gone to? RCMP. There's a few. It's an issue. I actually have had to try to actually put it in our curriculum as well, some of the very basics, the Internet governance and the fact that these public tools exist out there and what you need to do. So yes.
John Curran: Obviously it's very cost-effective for ARIN, because if you train them, then when they get frustrated, they're less likely to get frustrated and pick up the phone and call. And we'd like Registration Services Help Desk to be available to people making Registration Services requests. We don't mind taking the occasional call, but anything we can do to get education out there reduces ARIN's workload. So it's a proactive sort of preventive measure that's useful for us. Far right microphone.
Joe Morgan: Hello, my name is Joe Morgan and I'm with Joe's Datacenter. I had a question about how often when doing an investigation do you go all the way to actually contacting the abuse contacts and finding out more information from them or like the actual providers?
I've recently done a lot of research on accuracy of WHOIS data, even on my own home Internet connection and stuff like that, and business Internet, and I found that there's a lot of misinformation and inaccurate information. And I've had specific times where law enforcement has contacted me asking information about SWIP data that I have in the system.
When I ask for validation of them being law enforcement, the whole thing just drops. So with all these inaccuracies out there, my question is, you know, how far do you go to make sure that information is accurate? I use five to ten different IP addresses to browse the Internet every day and would hate for my information to be used in an investigation that I had no part of because the information was inaccurate and the proper steps weren't taken to validate that information before it was used.
Marc Moreau: As I mentioned before, and Bobby mentioned as well, the IP -- or the WHOIS information that's out there, for example, that is just a lead. There are a lot of other things that have to happen during the course of an investigation to validate all of the evidence that we're looking for.
Sometimes that can take a long -- it can be a long, drawn-out process that that occurs. But, yes, we have to make sure we corroborate whatever evidence we're looking for. It depends on the cases as well. Some cases are major cases and others can be handled quicker. But whatever information they do get, they have to corroborate that, especially if they're going to present the evidence before the courts. It has to be corroborated.
John Curran: Center rear mic, go ahead.
Geoff Huston: Geoff Huston, APNIC. I noticed in your presentation you mentioned obliquely with reference to ICANN the concept of putting impositions on registries not to give IP addresses or domain names or AS numbers to criminal organizations, if I've got that right. How would you see this taking place, insofar as it's very difficult, as far as I can tell, for any registry to divine what the intent of someone who wants an address might be, criminal or otherwise. So I'd like to understand a little bit more what's going on inside that area and what the motivations are.
Bobby Flaim: The motivations are we kind of looked at what ARIN does insofar as a lot of the vetting that they do when people are given IP addresses. There have been instances where we're just going to use -- we had an incident, one of the RIRs, where another law enforcement agency was working on a case and it looked like they had been given IP addresses.
And this also -- we were actually going to have a presentation here with the FBI concerning some people who actually were trying to obtain IP addresses that had been validated by ARIN and that there had been a problem insofar as the methods that they were using that they were criminals. So that's actually an ongoing case.
So when we talk about the issue that you're referring to, we're talking about the vetting of when anyone would try to come and get an IP address, such as we're also talking the same thing through ICANN, the registrars and registries and vetting, the person who is trying to get that information, we want to make sure that they are who they say they are.
If you're Joe Blow and you have a legitimate business, we want that information verified. Is it going to be perfect and easy? Probably not. But we were basing our model on what ARIN had done.
Geoff Huston: Thank you.
John Curran: Far right microphone. Anyone else who wants to speak on this, please approach the mic. Remote participants same. I'll be closing the mic for the presentation.
Gary Giesen: Gary Giesen from Advanced Knowledge Networks. First of all, I'd like to commend you both for coming here and talking with the community because I think that's very important.
But my question is: In light of FISA in the States and some of the abuses of security certificates in Canada, I'm wondering what else you guys are doing to try and rebuild some of that trust with the ISP community and foster a sense of cooperation in light of all the illegal abuses that have happened elsewhere? Because I know a lot of companies in Canada are reluctant to expand into the States or have dealings with the States because of some of the concerns about what's happening with their data.
Marc Moreau: I know that some of our field units, for example, they do reach out to their local ISPs, those that they deal with within their own communities. Does it happen in every one of the field units? Maybe not as much as we would like. But they do reach out. I think for most of them they at least have a contact that should something happen with their local ISP. So they are aware of the ISPs within their community, but beyond that maybe there are some bigger issues that we still have to work on for sure. I understand that.
John Curran: Thank you. All right. Microphones are closed. Last speaker, center rear.
Milton Mueller: Just a question.
John Curran: Name and affiliation.
Milton Mueller: Milton Mueller, Syracuse University in the U.S. We've been through a similar debate in the DNS WHOIS, and the form of argumentation that you're offering is understandable. You're saying it's very convenient to have this information at your fingertips, globally accessible and so on. And we certainly understand that.
The question is the convenience argument could be taken as far as you like. In other words, it would be convenient for law enforcement to have little Web cams installed in everybody's bedroom so they could see whether wife beating was taking place, it would be convenient to know everything about everybody before you let them have a computer, because they could be criminals.
So the question I have for you is: Where does it stop? What information would you recognize that you don't have a right to at any time and in all places and you would need to go through a process to get it.
Bobby Flaim: I don't think convenience is a way we would characterize it. These are public databases and we would like them to be maintained as such. We draw the line where the line is currently drawn. We want to follow all the laws, respect people's privacies. Everything that we obtain we make sure that we obtain legally through court orders, subpoenas, legal process.
What we're referring to here is a public database based on the infrastructure of the Internet that is very necessary and useful to the way we conduct investigations. So we basically are only asking for what's already there, and absolutely nothing more. We respect all the different laws of not only within the United States but within Canada and the other countries.
So I think we're very happy with the legal status of how everything works right now and that's what we want to maintain. We want to make sure we work through the system, not against the system and impose anything on anyone. So I think -- I hope that answers your question.
John Curran: Thank you. I'd like to thank our speakers.
We have a few minutes before the policy presentation starts. I've sworn I won't start any of them earlier. So I'm going to ask someone to come up and give an update on another initiative, our POC validation update. Thank you, Leslie.
Leslie Nobile: Good morning. Leslie Nobile, Director of Registration Services at ARIN. So I'm going to talk about -- this is actually very convenient, because we were just talking about WHOIS data. There's a policy called Identify Invalid WHOIS Points of Contact. It was ratified by the Board of Trustees, and we are about to implement this. It took some time. We had to get our software developed and the whole system developed. And we are going to just talk about the implementation plan.
Basically the policy says that ARIN will do an annual validation of all points of contact in the WHOIS database. So we're going to be sending e-mails to all points of contact and asking them to validate that their data is accurate or update it if it's inaccurate.
So the implementation plan. We're going to do this in two phases. We're going to start in June, early June 2010. We're going to be starting with points of contact that have direct resources from ARIN. There are about 42,000 of them currently.
We think it might take us about four months to complete. We're going to start by sending 5,000 e-mails each week to these people. We have the capability to actually throttle that up or back, depending on the response we get and how much work it ends up being, but we're hoping that we can maintain it at 5,000 per week.
It's going to be a fully automated process. It's going to be leveraging ARIN Online, our new Web portal. And let's see. So fully automated. The mail will go out and there's going to be a validate button. They can just click my "information's correct, validate," or they can click "I need to modify it" and it will take them through the ARIN Online system to update their information.
So at the end of this we're going to be sort of analyzing the effectiveness of it to see how it's working, to see if it has any impact on our day-to-day business operations, and we'll provide some feedback to the community at the end of this first phase to let you know how it's going.
So phase 2. After we've completed with the direct resources we'll start with the indirects. So we anticipate starting in early December. We'll be contacting all points of contacts with indirect resources or reassignments from upstreams. We currently have about 200,000 of them in our database.
We think it may take us about 12 months to complete. Again, 5,000 e-mails per week. We think this may actually take a bit more time. It will be a little more involved, because people with reassignments more than likely really don't know who ARIN is. So they may have a bit of an issue. They may have questions. So we just think it might bog down the process just a bit. That's why we're giving ourselves the full 12 months to complete it. Again, fully automated. And mid-phase we're going to do an interim analysis of how well the tools are working, what the impact is, and we'll try to report that back to the community at the next April meeting, April 2011.
So that's it. Just a quick update on what we're doing.
David Farmer: David Farmer, University of Minnesota and ARIN AC. Is there going to be a website where we can direct our customers, the rest of our community, to know about this effort so that when they get the e-mail they don't go, oh, somebody's trying to spam me, et cetera, et cetera, so that we can then -- so I can get the message out saying, this is coming, be ready for it, and then do it?
John Curran: Understood. Are you concerned predominantly with the second phase of the program, when we start contacting indirects, or you need the website now to describe--?
David Farmer: I think in general, I think that second phase is probably the bigger, in the bigger community problem. In the community I represent, in the R&E world, a lot of us have really old data in there. And so -- and probably haven't looked at it in quite a long time. So I think for the particular community I represent, it's more on the front side than the back side.
John Curran: So we should do a page that each can have that has why you're being contacted and sort of an informational page that you can point people to?
David Farmer: Yes. So when I go to -- actually, I have a meeting with Internet2 next week and I'll be doing an update of what occurred here. I'd like to be able to say, hey, this is coming; it's not ready yet, but I'll send you a web page that lets you get this out to the rest of all of the people that matter.
John Curran: Got it. We'll make that part of the roll-out. Any other questions? Thank you, Leslie.
We're back on track, and it is 10:00, which means timely for policy discussion.
John Curran: The draft policy we'd like to discuss is Draft Policy 2010-3: Customer Confidentiality. I'll introduce the policy and then have the shepherds come up and talk about their overview.
So history of the proposal. It was Proposal 95. It was submitted in 9 June 2009. The current version is the 2nd of February 2010. It was actually done by petition. So I forgot about this. Aaron Wendel, are you here somewhere? Very nice. Aaron Wendel has control of the draft policy as the petitioner. AC shepherds are Bill Sandiford and Owen DeLong.
The summary: Allows ISPs to substitute their mailing addresses and phone numbers in place of their customer’s when registering reassignment information. Requires ISPs to provide full customer information to ARIN when asked by staff. And stipulates that ARIN will hold the information in strictest confidence.
Status at the other RIRs. There are no similar policy proposals out there. AFRINIC and LACNIC and RIPE NCC, no such policy, to our knowledge. APNIC, similar policy in that by default reassignments are not displayed in the WHOIS.
Staff assessment. I'm not going to read the full legal staff assessment. But it does contain a little bit of risk in terms of implementation that people need to look at. You can go online to get the full legal assessment. But the term “in strictest confidence” could be subject to interpretation, and we could be held liable if we didn't comply with that in a way that it was ultimately judged to apply. And more precise language might be useful here before this goes to implementation.
Issues or concerns? None. Implementation resource: Minimal. That's actually something that I need to note. It's minimal unless adoption became pervasive and universal. And then at some point we need to figure out the hotline for calling up to get that information and how we would relay it if we needed it, because obviously it's possible that people would come to us to go get that information for various purposes.
So we don't see a big issue with it today. But depending on where law enforcement went, for example, this could become a significant issue.
PPML discussion. 72 posts were on the PPML list. Seven clearly in favor and 16 against. Some of the comments: Step in the right direction. It really should be between the ISP and the customer on who gets listed. Security might become harder because of this if people don't list their information. Any policy that undermines the listing of valid contact information is a step in the wrong direction. By being able to request some controls and tracking of how the information will get used, maybe we can keep the existing information and get better quality on what's there.
So that's the high-level summary and introduction to the policy proposal. You can find the draft policy in your folders. Again, you have a list of all the draft policies.
And now I'd like to introduce Aaron. Come on up and speak. And, again, this is Aaron Wendel. As the petitioner he has the option of presenting the policy proposal and his insight into it.
Aaron Wendel: I think I can get right and left. Everybody hear me? Testing. My name is Aaron Wendel and this is Draft Policy 2010-3. Let's see how this works.
Here's the policy text. ISPs may choose to enter the customer's name along with the ISP's address and phone number in reassignments and reallocations. In lieu of the customer's address and phone number, the customer's actual information must be provided to ARIN on request and will be held in the strictest confidence.
There were a couple of proposals yesterday and a couple of discussions yesterday that referred to this policy, and actually in both cases they inaccurately stated that this policy would allow you to obscure the name of the customer as well. The rationale behind this is pretty much a business rationale. Customer contact lists are one of the most proprietary and confidential pieces of information in any business.
The requirement for ISPs to publish those lists via SWIP or RWHOIS runs contrary to good business practices and invites competitors and others to solicit both individuals and companies receiving reassignments and sub-allocations from upstream providers. I've done a lot of research on this, and I have yet to find another private company that's required to publish their customer list in a publicly available database.
A little bit of history on this. This was actually borne out of a discussion that was on the ARIN Discuss List back in May of '08. Back then there were 74 posts from 19 people. So it got a lot of activity, or a reasonable amount of activity. Thirteen agreed that a policy was needed or thought that it was already in place. There seemed to be a lot of confusion about it. Two were against it. Four were -- I don't know if they talked about some Dean guy who needed to be banned from the list, and then the suggestion was made to create a policy proposal.
Of course nobody did that. Everybody was oh, this should be a policy proposal, this should be a policy proposal, so guess who stuck their neck out. Policy Proposal 95 was introduced on June 9, 2009. I revised it the next day because some people said it wasn't clear as far as what information could actually be substituted. At that point, back in 6 of '09, there were 117 posts by 29 people. Twelve were for, five against. Five others wanted modifications and seven, again, complained about some Dean guy.
Policy Proposal 95 was shelved for consideration by the AC until after the last meeting. They didn't feel that they had enough time to get to it. So it was put on the back burner. It was abandoned officially on 1-15-2010. I went ahead and petitioned it. And I received 20 posts of support from unique individuals. There are 10 required to get a petition passed.
So on 2-2 of 2010 it became what we see now as Draft Proposal 2010-3. Current stats. My stats are a little different than what John brought up, simply because my count started from when it became a petition. And his count goes from when it was actually determined to be a policy. So for the week or so before that there was quite a bit of activity.
So it's running 50/50. I have more slides here but I actually want to go off. I'm real happy that this policy has brought a lot of people to the table. There are people that have come out of the woodwork that have never posted on PPML before. There are a lot of people here that have never attended a meeting before. So I think that it's good that there's a lot of participation.
A lot of people have started to pay attention to these sorts of things that wouldn't before. I mean, law enforcement is here pretty much for this proposal. I really hope that it encourages more efforts by law enforcement to reach out to ISPs, instead of always assuming that they're the bad guys and that they're trying to hide somebody.
So yesterday I got into town, this is my first ARIN meeting, and I met with Einar, who, by the way, if you ever do a policy proposal, he's incredibly helpful. I also was fortunate to talk to David Huberman and Registration Services and Nate Davis over there hiding in the corner. These guys are all ARIN staff. These guys are really the unsung heroes of this whole process. They're very helpful. I had a lot of discussion with them yesterday. And then last night, at, I don't know, 11:30 or midnight, something like that, I spent some time with Tom Grasso from the FBI who was also very helpful and provided a lot of insight how this proposal would affect law enforcement and other industries.
So at this point, with apologies to the people who do support this, I no longer feel this policy is in the best interests of the community. I no longer support it and I'm withdrawing it.
I know some of you have whole dossiers ready to read at the mic. I didn't want to take anything away from anybody.
Scott Bradner: Scott Bradner, one of the Board members. A question came up at the head table. What's the process by which somebody proposes, gets it petitioned, approved, and then says never mind. To quote an old comedy routine.
I think it's perfectly legitimate both ways. You can interpret it both ways. It's new on the table and should be discussed as the PDP wonk as was described earlier.
I think it's perfectly reasonable to withdraw it, but it has raised a number of issues that probably should be discussed. So I would not want to take the withdrawal as taking it out of discussion.
John Curran: Full agreement. It certainly -- it was on the agenda. So it's entitled to discussion. And after the meeting, it will return to the Advisory Council as a live draft policy. Obviously they might take into consideration their prior thoughts and your recommendation in how they deal with it. But the microphones are open. The community's input is also essential here. Far left microphone, yes.
Bill Smith: Bill Smith with PayPal. And that was my initial question, was really for a point of order to ask whether it could be withdrawn. I'm speaking in opposition to this, and I very much appreciate the petitioner's withdrawing the draft proposal. At PayPal, while I personally do not do investigations, we do a number of investigations. We are required to investigate fraud. It also is good business for us.
The petitioner mentioned that he was unaware of any business that is required to publish their customer list, while the PTTs and AT&T or the phone company in the U.S. are not required to publish their lists, they do publish them. And every one of them, in fact, you have to pay to have an unpublished number. So there are examples of customer lists being published, and I believe that the business issue that was being attempted to address can be dealt with through legal means and potentially already is in the contracts that exist.
It's my reading of these, and I'm relatively new at this, but no service providers, no ISP, can use WHOIS data to poach customers. That's in some of the agreements that I have seen. And so I would urge that this policy, strongly urge that this policy not be adopted; and that while I also understand that it is critical to maintain confidential information, privacy information, hold that properly, I think we would need far more consideration and debate about how best to do this so that we can protect the information of the individuals, but also allow the Internet to be self-policed, because that's really how we're doing it right now. It is different.
John Curran: Thank you. Microphone, center rear.
Dave Barger: Dave Barger with AT&T. I'm going to go ahead and throw myself under the bus here. If you want to shoot arrows and throw rocks, that's fine. I think we still account for probably the majority of SWIPs that are in WHOIS. And a lot of those SWIPs recognizably are out there with private address information and things like that, this exact policy that was just demanded here.
But I do want to say we're in favor of a policy like this. We're constantly bombarded with pressure from customers to protect privacy. We have to keep that first and foremost in our minds, but, at the same time, the law enforcement discussions that took place a little while ago, there obviously is a need for law enforcement to get to this information.
So I guess what I'm saying here is something needs to be done. The process needs to be changed. And this has been brought up many times in past years; that what is the real value of WHOIS? What is it really there for? And I would have no problem providing ARIN with detailed lists, customer assignment lists, information that does have address information and all of that. But as long as it's something that is kept behind the scenes and on the side and used for purposes such as law enforcement investigations and that kind of thing, I would be in favor of that, that sort of WHOIS submission, but not have it appear in public WHOIS.
So I think it's important, and I don't think this needs to be abandoned, but it needs to be discussed, and we need to find a way to handle the process better.
John Curran: Thank you. Any comment? Far right mic.
Matt Sergeant: Matt Sergeant representing CAUCE. And also I have a statement here from MAAWG, the Messaging Anti-Abuse Working Group, which is the policy that CAUCE also supports as well. Certainly for anti-abuse researchers and investigators, many of which we -- we all are within MAAWG and CAUCE, system operators and so on, WHOIS is an essential and basic tool for us to start those investigations. The investigations that researchers start often do lead on to law enforcement action. In fact, there's a very -- there's very much a close operation there between law enforcement and community researchers.
So restricting WHOIS data purely to law enforcement would very much stunt community research and therefore have a major impact on law enforcement. Hiding the true owners of these resources will increase mistrust of the Internet, and certainly, if this becomes an ARIN-only policy, will create an influx of those bad actors towards the ARIN resources as they try and find the places where they can hide more deeply.
The policy as it stands at the moment doesn't seem to really provide that much security, just providing the business name. Pretty much still gives you access to an address, just Google it and you'll be able to find the address of a business, anyway. So it's really not a strong policy in terms of hiding the information. You'd have to go much deeper for that. So we see, CAUCE and MAAWG, see no benefit from removing this key information from WHOIS. We're skeptical that this would have any particular benefit to those organizations providing information there.
MAAWG and CAUCE firmly oppose the adoption of this draft policy. We request that ARIN ensure all contact information published in the WHOIS database is up to date and correct for any resource holder to continue to use as a basic tool.
John Curran: Thank you. Far left mic.
Chris Morrow: Chris Morrow. I work for Google and I'm on the ARIN AC. I didn't support the policy. But this isn't really about that. The guy from AT&T, if you want to hop up to the mic really quickly. Dave, you mentioned that there was a bunch of private data. That's private residents' data.
Dave Barger: This goes back to ARIN Policy 2003-something, the residential privacy.
Chris Morrow: You can zero all that out; your OSS just isn't doing it for some reason. You can zero all that out and put in your information, right, and your OSS is just not doing that for some reason and you're shipping the SWIPs up with the information.
Dave Barger: Basically it was targeted at our DSL business.
Chris Morrow: 2003, seven years ago.
Dave Barger: That's right. Targeted at the DSL business. The way automated process works, it substitutes private residence.
Chris Morrow: Verizon does the same thing. My point is if your discussion point is about private residences, it's already covered. It's already safe to remove that from your perspective.
Dave Barger: That is covered. I didn't mean to advocate up here that we stop SWIPing every piece of information. To me this policy didn't come out and say this is just for businesses. So maybe there needed to be some clarification there, too. But clearly for businesses, and the comment was made a minute ago about Googling business names and things like that, you can clearly get that kind of information off their web page. I'm not advocating that we just stop SWIPing address information for every entity that's out there. So thank you for bringing me up here to mention that.
Dave Barger: I think that is to be considered. Just because we're asked routinely to do that by the businesses that are our customers. So somehow we have to deal with it if possible. And the way of dealing with it up to this point is, sorry; you gotta put your address out there and live with it.
John Curran: Does that address, Chris, what you were asking?
Chris Morrow: Yes. He mentioned something that sounded to me something like the residential policy which was already taken care of. So if there is some fear from business folks -- so as a Verizon customer I have a business service, and they promptly put my personal information in the WHOIS. So I called them up after talking to three different representatives, as an employee of the company, right, they were telling me it's against the law for them not to do this.
So there are educational information problems inside of companies like AT&T and Verizon. But as far as residential stuff, that's already covered. So if it's just a business concern, then maybe you should talk to Aaron see if he wants to resurrect it or write one yourself.
John Curran: Center front mic.
David Williamson: David Williamson, Tellme Networks and Microsoft. I want to thank you for coming and presenting a proposal. It's nice to see new faces presenting proposals. I'm against the proposal as written. I think we hashed over the reasons. I want to highlight my employer actually took the time to respond on PPML for anyone who hasn't seen that.
I'll spare you reading the entire message. But I wanted to highlight two sentences of it that I think are key from Microsoft's point of view: We oppose any policy change that would lessen the quantity and quality of information in the ARIN database. While we recognize the importance of data privacy, we strongly believe the proposed changes would only hamper the security community's ability to investigate and mitigate cyber crime. I think that really sums it up pretty well.
John Curran: Thank you. We have someone at the head table.
Marla Azinger: Marla Azinger, Frontier Communications. I am opposed to any changes. I believe all the information should be in there. And anybody that tries to use a business case reason where they're saying they're losing customers because it's easily mineable to get customer bases, you need to change your business. You're losing customers because your business is bad. It's not because someone got information out of WHOIS.
So that excuse kind of just really needs to go away. And I would suggest you kind of look at what else is going on with your company, if you believe that's what the real cause is. I think all my other points were addressed. But I do advise the local police department in the town I live in as well. And as much information is in WHOIS, there's also still training that needs to be done with people. And that's why I advise them, because it makes it easier for them to get the subpoenas that they need faster.
I can't go into details, but recently I had one. And it would have taken them at least a long -- somewhere around three weeks to get something that they needed in 24 hours if WHOIS didn't exist. So it needs to be there.
John Curran: Far right mic.
Heather Dryden: Good morning. My name is Heather Dryden. I'm with the Canadian Ministry of Industry. And I'd like to speak against the proposal and thank Aaron for withdrawing it. What I wanted to point out and I think it's already been touched upon this morning, is this notion of privacy. It's popped up a few times. A few speakers have mentioned it. In the Canadian context, if you're talking about privacy, you're talking about individual privacy.
If you are a business, that is a very different matter. And the expectation on businesses is that they would publish full contact information, and there are various instances where there's legislation, for example, labeling of products. Where companies are expected to identify their address on those products.
Also, the regulator, the CRTC, publishes full information that includes address and telephone number of everybody that's offering a telecommunication service or is reselling the service in Canada. And the reason that we do this or expect this as a good business practice is because it's in the public interest; it's in the interests of consumers to do so. I won't talk about law enforcement. They're certainly able to articulate, and have already, the concerns that they have, but I think it may be helpful to the discussion to talk about from more of an Industry Canada perspective, how we would view that. So thank you.
John Curran: Thank you.
Aaron Wendel: One of the primary drivers behind this proposal originally was the emergence of end users, people who either work out of their house, run businesses out of their house, or Bob down the street who decides him and his five friends want to get together and rent a server for their gaming lan, for example. So they're not really a commercial entity. They're more of a private entity or a residential entity, almost.
So that was one of the drivers. And also in some of my discussions yesterday, again, I'm not a lawyer and I'm not even a Canadian --
-- But is one worse than the other? I'm just kidding. I've already stuck my neck out there far enough. Everybody keep your hands down.
I guess there's a law that says that if the customer's residential in any way, then I'm not allowed to -- if I'm a Canadian-based hosting provider or a dedicated server provider, that sort of thing, colo provider, I'm not really allowed to release anything. If I SWIP any information, including the customer's name, then I'm in violation of Canadian law.
Now, again, the guy -- the couple guys who told me that weren't lawyers either, but that seems to be the understanding, anyway, that they had.
John Curran: So, clearly, if there's someone who is a Canadian lawyer, specializing in this, they need to come forth and talk about that before this group so we can have something authoritative, but we haven't heard that definitively from anyone at this point. Thank you. Center rear mic.
Milton Mueller: Milton Mueller, Syracuse University. By the way, these are great, the discussion guides. These are really nice. Very useful. I didn't know whether to support this thing or not, actually. I had supported the intent of the policy as a privacy advocate. An individual rights advocate, I thought what you were trying to do was worth talking about.
But there were legitimate concerns raised about the drafting of the way the proposal was drafted, the kinds of obligations imposed upon ARIN, which made me waver and think that this could be improved. When you get up and tell me that last night you were visited by the FBI and you changed your mind --
Aaron Wendel: Please release my family.
Milton Mueller: -- I want to know more about why you're changing your mind. Is it because this is not drafted properly, needs to be changed? Is it because there's this question about the effectiveness of it that have been raised, which I think are persuasive about whether this information can be gotten in other ways. Why did you withdraw the proposal? Can you tell us more about that?
Aaron Wendel: I think that there are a lot of different needs from different -- not just law enforcement and not just the ISP community, but also the educational institutions and everybody who has any sort of address space. And there are varying needs of information.
And I guess that I have to say that, you know, again, after -- I didn't mean to make it sound like the U.S. government cornered me and threatened me or anything, because that's not what happened at all. It was very good conversation, and very educational for me.
And it wasn't just that conversation that I should say changed my mind. It was also my conversation with several members of the ARIN staff. It was kind of a collection of everybody that I talked to yesterday that I really felt that this policy was -- while there needs to be some clarification in the ARIN policy manual, I didn't really feel that this did it and that this might open other cans of worms that I wasn't aware of before.
John Curran: Just to ask a follow-up question. While this may open up other cans of worms, I guess you did say, well, there needs to be clarification in the ARIN policies. More specifically, if not this proposal, is there a proposal or something that you think -- what do you think should replace it instead, I guess, if that's what you're advocating?
Aaron Wendel: On the three hours of sleep I got last night and the 24 hours that I've really been deep in thought about this, I don't have a good answer for that. I'm sorry.
John Curran: Okay. Thanks. Center front mic.
Owen DeLong: I think he was ahead of me.
John Curran: Far right mic.
Tom Grasso: Tom Grasso, FBI. First up, I want to thank Aaron for bringing this proposal forward, even though we were on different sides of the proposal. I think this is a very important discussion that we're having. So I think this is great that we're all here right now and enthusiastically talking about this, because I think it's an important issue.
Bobby and Marc did a good job of explaining why the WHOIS data is important to law enforcement. So I don't want to talk about that. But the reason I wanted to come up here and speak was just to follow on or add support to what Bill from PayPal and Matt from CAUCE MAAWG were saying, and that is just to let everybody know that the job I do as an FBI agent of investigating computer crimes and trying to track down computer criminals is very dependent on the assistance that I get from people like everyone in this room, people that are from private sector, from academia, people that are outside of government that are policing the Internet, that are -- and you all know who you are -- the white knights of the Internet that are keeping the Internet running in spite of all these problems that occur on it, that community is very, very important to us in the job that we do.
We wouldn't be able to do that job in that community, and, dare I say, most of what we do, probably 90 percent of our successful cases are a result of that community. So I think the more that we can enable that community to have access to this type of data, the better. The gentleman from AT&T was talking about, well; maybe we could have some way to have just law enforcement access to this data. And that's what made me decide I should stand up and say something. Giving law enforcement access to this data, only giving law enforcement access to this data is not a good thing in my view.
Yeah, I can always get it with a subpoena or court order. It's going to be too late in most cases, but at least I can get it. But I'm more concerned about the people that are outside of law enforcement and them having access to this data to help police the Internet and keep the Internet running. So that's all. Thank you.
John Curran: Center front.
Owen DeLong: Owen DeLong, ARIN AC. I want to thank Aaron for bringing it forward and abandoning it. I think both of those acts took a lot of courage.
Aaron Wendel: I thought I saw you have a seizure over there.
Owen DeLong: It did come as a bit of a shock, yes. But I was very glad to see that. There's definitely work to be done in this area. I think the AC is aware of it even a little bit before this, and certainly now. And I think that there will be some stuff done on it. But I do agree this is not the right proposal and in the best interests of the community. I don't think that will come as a surprise to anybody here. And I want to thank you for being so forthright about it.
Aaron Wendel: Thanks, Owen.
John Curran: Center rear mic.
Marc Crandall: Hi. This is Marc Crandall with the ARIN AC and with Google. I personally was against this proposal. But what I think is interesting is how the discussion has turned from protecting customer lists to privacy specifically. And I think we should also keep in mind that, ultimately, in order to associate a single IP address with a single user, one would technically or theoretically need a valid legal request from law enforcement, which would require vetting from a court.
So you theoretically would not be able to look up an individual user, not someone associated with a business, and perhaps you have that issue about people putting together a group to run some sort of game server, but you still would not be able to associate an individual with a particular IP address that is a non-business without a court order and some sort of neutral third party reviewing it. At least in the jurisdictions that are covered within the ARIN region. That's all I have to say. Thank you.
John Curran: Thank you. Microphones are going to be closed shortly. If you're going to speak on this, please move to a microphone ASAP. Same with remote participants. If you want to get in the queue, do so immediately. Okay, far right mic.
Kevin Blumberg: Kevin Blumberg from The Wire. I initially supported some aspects of this proposal but overall did not support it. My initial concern is that what I'm looking for is better clarification on residential customers, not just with DSL. But at the same time I understand that having valid information is important.
My question actually is to ARIN as a whole is what is available as far as if there was abuse of this WHOIS information? What teeth does ARIN have, and has ARIN ever done anything? So if there have been complaints about abuse with WHOIS data, has any actions been taken and is that maybe an option in the future?
John Curran: I can say right now the WHOIS data, we actually rate limit queries against the WHOIS database to prevent mining of it. It's available in bulk, only under the bulk WHOIS AUP. At present we haven't had a circumstance where someone's come to us and said: I think I was abused from the ARIN WHOIS database and I need ARIN to take action. We haven't had anyone raise that to us, so we've had no reason to have to pursue it.
Obviously if someone complains, we'll try to hunt it down, because if it's systematic, it shouldn't be hard to find the bulk WHOIS origin. If it's a one-off case, because the data itself is public, it's next to impossible to determine whether or not something was appropriate usage. Again, the only time we actually have a contractual relationship is when someone does the bulk WHOIS download and agrees to the AUP.
I'm closing the microphones. Last chance. Three, two, one. The queues are presently closed. Please don't join the queues. We'll process the current people. Center rear mic.
Danny McPherson: Danny McPherson, Arbor Networks. I had a question for Dave. My day job is with operational security. And I know AT&T actually does a really good job on following up on abuse complaints, for example, and so I was just wondering if -- and I see he's in the back behind me here, so he can comment to this in a moment -- but if he's speaking for all of AT&T with that comment.
I know it's tough to put him on the spot, because I know that his teams at AT&T, the security teams, employ this data daily and do a good job with it, and I can't believe that they would like to see that go away.
John Curran: Okay. So that's a directed question. Dave, do you want to step to the front of the microphone and respond?
Dave Barger: And, I'm sorry, I didn't hear like the last sentence of that standing back there behind you. Can you repeat?
Danny McPherson: I was just asking if this sort of an official position of AT&T. Because I know AT&T does a good job. And when you're here at the microphone and say, hey, AT&T doesn't want this, and I know maybe they don't want to share their information but they want everybody else's --
Danny McPherson: In all honestly, AT&T does do a good job on following up on abuse, and I know they employ this information, so that was basically my question.
Dave Barger: I'm not going to stand up here and say this is the official position of AT&T, first off. Many of these are my opinions and my views as custodian of the IP address space for AT&T. So I guess my points earlier and comments -- I wanted to throw one other thing out here for thought -- is that this has been going on over and over and over again. There are some processes here that I believe need to be changed. Do I have an answer for that? Not really right now. But I'm going to go back and think about it some more.
But the other thing about omitting information from WHOIS, you know, address information, after sitting down here and talking to Judy and thinking about who we are approached by, and these are the business customers that I'm talking about, probably the majority of those are law enforcement and government agencies. We have a lot of those as customers. If the FBI comes to us, the Dallas branch office, and says we have this circuit, we have this address space, but we'd rather not our name and address show up in WHOIS, then we find a way to mask that. And I know there's no policy to cover that.
That's one thing I think we really need to take a hard look at is -- from a security perspective is how do we protect the information for our law enforcement, for our government agencies, city government, you know, all of that kind of thing. And we have thousands upon thousands of those kinds of customers. So that's something that I think we need to put some thought into.
John Curran: Thank you. Center rear mic.
Rob Seastrom: Rob Seastrom, Afilias, ARIN AC, and Seastrom Consulting, which is the hat I have on right now, for reasons which will become obvious in a moment.
Everybody has different levels of privacy concerns and different levels of information that they're willing to have out there, and that's a situation that sort of transcends the IP address space issue. It's a global level of what information am I willing to put out there about myself and in what forms and am I willing to -- and am I willing to take affirmative steps to have certain information masked as part of my everyday life.
So my -- I hold ARIN legacy resources. My org ID are my initials. They're assigned to me personally from pre-ARIN days, not to a corporation. The contact information on those resources is a post office box, which keeps people from showing up on my doorstep, and my cell phone number, which is never turned off. People can call me at three in the morning if they like. I don't guarantee that I'll answer. But that's the level of having that information out there publicly which I'm personally comfortable with.
In response to David, I'd like to say that these organizations are more than capable of setting up front organizations for themselves. They do it all the time. I have the capability of as part of my daily life, not just as part of in my dealings with ARIN, setting up Mail Boxes Etc. or a legitimate post office box or whatever so people don't show up on my doorstep. And so the masking of the customer data is something that people can integrate into their regular level of privacy concerns.
John Curran: Okay. Thank you.
Aaron Wendel: That was one of the things that came up yesterday is that there were other ways to accomplish some of these goals. And that didn't necessarily require a new policy, and that was -- again, there are so many different facets to this that unfortunately two sentences just weren’t going to satisfy everybody. So that's one of the reasons why I chose to withdraw.
John Curran: Got it. And final speaker, center rear microphone.
Lee Howard: Lee Howard, ARIN Board of Trustees. Certainly not speaking on behalf of the board. My day job is Time Warner Cable. I say that for affiliation. Also not speaking for them. But I wanted to say I'm incredibly proud of the process. I'm being a little self-referential for the policy development committee that I talked about before. The fact that there was a proposal that went to the Advisory Council and the Advisory Council said "ehh" and the petition process worked. And then the person who took it to the petition process came to the meeting and talked to more people and changed your mind. And we still had this conversation. And I'm overwhelmed with pride in the organization that we have, the fact that the staff was so supportive of such a controversial proposal is -- I'm really proud, almost got a tear in my eye for being a part of this organization's community.
John Curran: Thank you.
Well, with that praise, to ARIN and Aaron, I'd like to thank Aaron for presenting and we'll move ahead. Thank you.
Aaron Wendel: Thanks, John.
John Curran: It's nice to see some part of Internet policy process working in the world. So we're now at the point in time when we're moving on to the break. We're going to have a break, which has been slightly abbreviated because of the discussions. We will pick up and resume exactly on time, which is 11:00. So if you head outside you'll find refreshments. Please be prompt in getting back here. We'll pick up at 11:00 with Draft Policy 2010-6: Simplified M&A Transfer Policy. Thank you.
John Curran: Policy Proposal 2010-6, the history: Introduced on the 22nd of December 2009. Current state is the draft policy as of 23rd of February. The shepherds are Scott Leibrand and Bill Darte.
Summary of the policy - again, you have the full text in your listing of all the draft policies - states that ARIN will consider transfer requests that have proper documentation either at the time of the merger or acquisition or anytime thereafter. It's to clarify the terms that we use in approving a merger and acquisition transfer.
Clarifies that unused space is to be returned to ARIN. So at the time of the transfer, space that's not in use does not transfer; it gets returned to ARIN. Status: Draft policy is unique to ARIN. Other RIRs do have merger and acquisition policies. They don't currently have a similar policy proposal to make these clarifications to their M&A policies.
Staff assessment, liability risk, staff concerns and comments. The issues and concerns is that when we ask for detailed information for transfer requests, that's generally during an M&A process. We already have the circumstance when we ask for that information that organizations abandon their process. They say never mind, don't change the records, and they simply abandon the transfer request that they put in.
So because that's the case, it's possible that even though we clarify this procedure that it actually won't make a difference, because some organizations simply have a problem with supplying that information because the amount requested or the complexity, and so this further makes clear that unused resources need to be returned if we are presently not having people complete the M&A transfer process. And we make it clear that unused resources in that will be returned, that might actually create a lower rate of people updating the records than we have today.
It will be a resource impact because we need to follow up on this. We need to make sure that resources are unused and ask for the utilization information so there could be a moderate level of resource impact and that's something that the organization needs to pay attention to since this type of work has a cost-benefit tradeoff to the community.
PPML discussion: The discussion occurred on the original proposal, things submitted as a proposal, and then when the AC picks them up and works on them, they become a draft policy.
On the proposal, there was quite a bit of discussion when it was submitted. Fifteen posts by six people. Three in favor, one against. A positive move ensures that ARIN's policy does not put a barrier in the way of M&A activity.
Do we want organizations to voluntarily initiate 8.2 and M&A transfer? Renumbering legacy network where everything works just fine, just adds to acquisition costs, and we need to talk about the number resources of the resultant combined organization rather than the acquired merged organization.
During an M&A we're only looking at what is transferred as opposed to the entire combined entity. That could have synergies there. So this proposal is only talking about the organization that's being acquired or merged in.
So that completes the introduction of the Draft Policy 2010-6. I'd like to invite the shepherds up now to do their presentation. Scott?
Scott Leibrand: So we've already had the introduction from John. Thank you. What are we trying to do here? So at the last ARIN meeting, we had a couple of comments from the floor. It was a joint NANOG meeting. So some of those are from operators as to a couple of things they noticed with existing M&A. In addition, we had a staff experience, policy experience report from Leslie as to what they did.
The problems highlighted there were a couple-fold. It wasn't clear to certain lawyers -- Igor was the one that brought it to our attention -- that whether M&A transfers and transfers to specified recipients were an "or," like you either had to have this or that, or if it was an "and," you had to have both.
It never occurred to me that would be a confusion. But it was, so we're trying to fix that. In addition, the experience report highlighted that there are a number of procedural issues that come up when people try to do M&A transfer. So we got this policy together in an attempt to address those issues.
So this Draft Policy Proposal clarifies that you can transfer under M&A or you can transfer under transfers to specified recipients independently. The two are not conjoined in any way. It simplifies the transfer policy. I think we cut it down to less than half the length of the previous policy.
It allows M&A transfers to be completed based on overall usage. So if someone acquires a company the current policy says that that company, when they were being acquired, had to be using this space.
Companies being acquired often have weird networks and are not doing things quite right. But the acquired company often integrates them and gets things into shape. This allows that integration to become the basis for keeping those resources.
And it directs ARIN to work with the resource holders to discover anything that is unused after that point is not going to be needed in the next year or whatever the current policy says is the guidelines for new space and return that.
So this is in your packet, but it's fairly simple. ARIN will consider requests for the transfer of number resources in the case of M&A upon receipt of the evidence that the new entity has acquired the assets. This is already the same stuff in there.
And in the event that – this actually addresses one of the staff comments - in the event that the number resources of the combined organizations are no longer justified, then ARIN will work with resource holders to return to aggregate, whatever. So that comment actually resulted in a change in the policy. So this got updated since then.
And then of course the last thing, the - in addition to transfers under 8.2, makes it clear it's either one or the other.
So these are fairly simple clarifications and simplifications. In my opinion, the -- and you can read the entire rationale, but basically in my opinion what this does is it makes it much easier for transfers to be completed. But it also addresses the issue that John was talking about, about whether or not such transfers will be completed by an organization once they're brought up.
The way it does that it basically says once ARIN finds out about a transfer, via -- excuse me. Once ARIN finds out about a merger or acquisition or such through any means, whether it's a transfer request or anything else, ARIN is responsible for following that up and making sure that unused resources are taken care of.
So the incentive for an organization who is not fully utilizing the resources to just go away so they don't have to deal with ARIN is gone, because ARIN is responsible for following up with that organization. If the organization doesn't cooperate, at the end of the day they can revoke addresses that are not being used.
And given that we're this close to runout, I think that's incumbent upon us to do. But it also encourages people to just go ahead and do the right thing, finish up your transfer request, we'll make sure that you've got enough addresses for what you need and we'll make sure we give you time to renumber out of and return anything that you're not using.
There were a couple of questions that came up during the discussion. And these address those. I'm not going to read those, but if anyone has any other clarifications, we can talk about that. So, any questions, comments, feedback?
John Curran: Microphones -- the microphones are open. Remote participants and questions from the floor. Marla.
Marla Azinger: Marla Azinger, Frontier Communications. I support this proposal, but I would like to know -- it only addresses one side of the scenario. What if there's an acquisition but the numbers that those customers are using don't come with the acquisition? What if the purchase is done and all the IP addresses that those customers are using have to go back to the selling company?
Scott Leibrand: So the way that the original policy is written and the way we continue to do it is it says that the transfer of number resources in the case of M&A upon receipt of evidence that the new entity has acquired the assets that used the transferred resources from the current registrant.
So if you -- if the company has a network or whatever other stuff and that uses addresses, the company is acquired but the network is given to somebody else, or the customer base is given, whatever, the things that use addresses are given to somebody else, the somebody else is the one that is the one that qualifies to receive that transferred addresses, or, if that's the same organization, then obviously there's no transfer.
So I don't think this requires addresses to be transferred with the company; it allows addresses to be transferred with the assets that were using those addresses to begin with.
Marla Azinger: Right. So you're only accounting for that. So if I sold state of such and such to another company and said: I want the IP addresses, though; I'm selling you the customers, but I want the IP addresses, so that now I have all this extra address space.
Scott Leibrand: I don't believe that is allowed by current policy.
John Curran: If I could jump in. As it turns out, it's not possible for ARIN to direct an entity to transfer addresses as part of a sale and acquisition process.
So we have had a case where organization has transferred a portion of an operational network but indicated that the customer and routers are going but someone will have to renumber all that because the addresses that were being used they're going to use elsewhere.
And I guess this proposal doesn't change that, because if the recipient doesn't have -- isn't told that they're receiving the addresses as well, then it never comes up in the M&A. So I think it remains equally a problem under the proposal as it was before, if that answers the question, Marla.
Marla Azinger: Yes, it doesn't address that problem.
John Curran: Center front mic.
Owen DeLong: Owen DeLong, Hurricane Electric, ARIN Advisory Council. In regards to the staff concern about we already have people abandoning their transfer requests because we asked them for detailed information, will this make it worse, it would seem to me if you have somebody come in and make a transfer request, and when you say we need you to show that you actually qualify and they go "never mind," that that would be a really, really good opportunity for Section 12 of the Policy Manual to come into play with a resource review, which is kind of the kind of thing we wrote the Resource Review Policy for.
I think that we do need to try and find a way to address the situation where Company A sells a substantial operating network to Company B. Company B does not get the addresses with the operating network and comes to ARIN and gets yet more addresses for the same set of customers and equipment and whatnot. And Company A is now sitting fat, dumb, and happy with this big pool of addresses they're no longer using.
I think that it would be good if Company B let ARIN know that was the case. And Section 12 could again come into play towards Company A, whether or not ARIN has any ability to say, yo, Company A, you sold the customers, the resources go with them.
John Curran: So let me pick up on that. I do believe Section 12 could be used to address that. This is in the case that I'm aware of. It's a recent development.
I guess to give you the staff comments, all we're noting is that while all the tools are presently there, calling them out in this policy proposal to someone who then has to submit an 8.2 M&A transfer request may give them pause not to start the process, because it's so clearly laid out that if you start the process, we will complete it for you.
Scott Leibrand: Are we being a little too transparent here, John?
John Curran: All I'm pointing out is that this will obligate ARIN to do something. There's nothing wrong with that, but it may cause some people not to bring it to our attention.
There's an implied part of the policy -- not implied. There's something you said in your introduction which isn't in the policy. That is if ARIN hears of an M&A it shall go forth and initiate this on its own, which isn't clearly in this proposal and -- but it was implied in your introduction.
Scott Leibrand: It's also implied here, I think, in that through a transfer request or otherwise. Yeah. I mean, I could be more clear, then we run into the same problem.
Owen DeLong: I would tend to think that one side of the other transaction ends up not keeping the address space and that side is likely to want to make ARIN aware of the fact, whereas the side that gets the address space may or may not want to make ARIN aware of that fact.
So I think as long as one side has an interest in making ARIN aware of the fact that the resources have been transferred, it's probably sufficient. And I don't think this policy detracts from that. I'm in support of the policy.
John Curran: Good to know.
Kevin Loch: Kevin Loch with Carpathia Hosting. If I could speak just as one data point about this scenario where you initiate a transfer request and then abandon it because it's too much hassle.
I've personally gone through that. And it's really not that it was too much hassle, but that involves parts of the business that have the contracts that you need to dig up and a lot of times that you just don't have the time to do that. There are more important things going on in the business.
And in some cases it's possible to go on using the old name because it's possible to update the contact information. It's only the org ID that's different and you can just deal with that scenario, and it really is -- I think that's probably not an uncommon scenario.
John Curran: Understood. Center rear mic.
Aaron Hughes: Aaron Hughes. First, I support the policy as written. I think it's a nice step forward. I would also like to say I don't think it's enough. There are probably about to be a lot more M&A events happening in the near future. And it would be probably appropriate to account for people with a little more strategy in mind about acquiring assets and potentially acquiring for the purpose of either combining them or just reselling them.
And it would be nice to have a time window in there where these policies don't necessarily apply if you're intending to resell that asset or change the asset into something else and resell those objects.
There are plenty of times where if you acquire a small asset as a larger entity, it becomes less valuable if you have to spend time renumbering those customers before you can sell it off to someone else.
John Curran: To make sure I understand the change you're talking about. I'm not sure I understood. This doesn't apply if you're presently considering -- could you repeat that?
Aaron Hughes: On occasion for strategic purposes you might acquire a small company that has some ARIN or other resources associated with it that you don't -- you don't ever intend to move the customers to your space, even if the current ratios aren't being met by the company you're picking up. And you may want to resell that entity rather than integrate them into your existing systems. And it becomes less valuable for you if you have to put more work into it to renumber those things and then turn it yet into another spin-off that you can later sell.
If you intend to do that in some small window of time, say 90 days or something like that, it might be useful to not have to go through this process in order to acquire that asset.
John Curran: Okay. So let me raise -- now I understand. I was just going to raise a question so I get -- one thing that this does sort of do is an entire shell company purely for the transfer of addresses would be very difficult now to successfully run through the M&A process without having a full resource review that runs to conclusion.
The hypothetical you carve out would handle the case of someone acquiring an entity that they intend later on to sell because it's not going to be integrated into the main business but it would also handle that case of a shell company with addresses only.
Aaron Hughes: I realize it opens up some room for some nasty things. Don't get me wrong. I'm just saying that there will be a lot of -- there are today a lot of small businesses that will fail without being acquired.
And, strategically, you may not want to get into the business you acquire. I'm just saying put on some M&A hats from a business perspective and keep in mind the fiduciary responsibility of the entities that are acquiring some of these assets and reselling them over time.
John Curran: There's definitely costs involved.
Aaron Hughes: I realize it will be hard to address. I'm just bringing up a point.
Scott Leibrand: I'll be happy to work with you if you want to do a follow-up policy to help address some of those issues.
Aaron Hughes: Absolutely. And I still do fully support the policy.
John Curran: Microphones are open.
John Sweeting: John Sweeting, Time Warner Cable and Advisory Council. So, Scott, under this, would 8.3 be an option for the people covered under 8.2?
Scott Leibrand: In some conversations I've had, it sounds like 8.3 is currently being used, and in at least one case has been used for a transfer that could have also gone under 8.2 but it was easier, better to put it under 8.3.
John Sweeting: No, what I'm saying, where you say through ARIN will work with the resource holder to return, aggregate or reclaim resources, could it also be an option that they use 8.3 to get rid of those excess resources?
Scott Leibrand: I would have to look closely at exactly how 8.3 is currently worded as to what it allows. But my memory was that 8.3 is supposed to allow you to transfer resources without automatically triggering a resource review. So there may be ways to do that.
John Curran: If a party was to show up and say, as part of this activity, we're doing a merger -- we're transferring resources to this entity which is undergoing an 8.2 merger and acquisition process, and the remainder of our resources are going to 8.3 to be designated, that would be fine. There's no reason why that couldn't occur.
If I follow the advice that Owen gave from the floor, which is when seeing a transfer of assets that don't include all the IP addresses, and we independently invoke a resource review on the holding organization, then once we start the resource review, you don't really have the option of a transfer.
So you'd really want to make sure you do the designated transfer and the merger and acquisition pretty much at the same time, unless ARIN started a resource review on the process on you.
John Sweeting: That would just be a tweak to the second paragraph to indicate that they could do that, if we decide that they could.
John Curran: Microphones remain open. Remote participants -- remote participants as well.
We've had several speakers come to the floor in support of the policy proposal. It would be good to hear from those who have arguments again the policy proposal so the AC can hear well-phrased both sides of the argument.
Well, that requires someone to actually speak. I'm closing the microphones. Closing the microphones in another moment. Microphones are closed.
Scott, thank you for your presentation.
Okay. Having had that policy proposal presented, and I see it's an opportunity to gauge some feedback for the AC to do its job. So we're going to have a show of hands about advancing that policy proposal. So I'm waiting for our tabulation machine to be ready.
They're in place. I remind remote participants that you can also participate in this. Instructions to that are online. Do we have a remote participant tabulator? Okay. Good to hear. Okay.
So on the matter on the table of Draft Policy 2010-6: Simplified M&A Transfer Policy, I'm going to ask for a show of hands. I'm going to ask first for those in favor, and then I'm going to ask for those opposed. When I ask, raise your hands nice and high.
Okay. All in favor of Draft Policy 2010-6: Simplified M&A Transfer Policy, raise your hands now. Everyone can participate. Raise your hand now.
On the matter -- thank you. On the matter of 2010-6: Simplified M&A Transfer Policy, all those opposed raise your hand now. Nice and high.
Okay. Thank you. That's being tabulated and the results will come up. I guess I wanted to be clear. ARIN policy meeting and consideration of policy proposals is open to everyone. So that means that you don't need to be an ARIN member to participate in a show of hands.
If you're here and you have interest in a policy topic and you want to participate, you are free to raise your hands. We ask that the ARIN staff obviously not participate, but otherwise this is your meeting.
Scott Bradner: John, while the results are being tabulated, I'd like to actually revisit history and point out, we didn't do a show of hands for the previous policy discussion, and it probably would be instructive to do so.
John Curran: Okay. Actually since it goes to the AC, I'll ask Mr. Sweeting, do you think we need a show of hands for the following one, will that be helpful?
John Sweeting: I think we should have it, just --
John Curran: Not a problem.
John Sweeting: Just to complete the record.
John Curran: Sure. On the matter of policy proposal 2010-6: Simplified M&A Transfer Policy, number of people in the room and remote, 134. Number in favor, 57. Number against, four. This information will go to the AC for their consideration.
It's been brought to my attention that we did not do a show of hands after 2010-3: Customer Confidentiality.
So we'll correct that right now. The tabulation machine is still here. So we're going to have a show of hands regarding a prior discussed policy proposal. This is Policy Proposal 2010-3: Customer Confidentiality. I'm going to first ask for everyone in favor and then I'm going to ask for everyone opposed. When the time comes, raise your hand nice and high and hold it until I say okay.
All right. Those in favor of Draft Policy 2010-3: Customer Confidentiality, raise your hand now. Nice and high.
Okay. All those opposed to Policy Proposal 2010-3: Customer Confidentiality, raise your hand now. Nice and high.
The beneficiaries of ARIN's informal exercise program.
Now switch hands.
I look very poor in spandex, I promise.
Scott Bradner: John, I didn't need the image just before lunch.
John Curran: Just for you, Scott.
They're tabulating now. Should be here in a moment.
I'll describe the upcoming agenda. We're done for the policy proposals for the morning. Right after this count we'll have Einar Bohlin come up and give the Regional Policy Development report, which highlights what's going on in the other regions.
On the matter of Draft Policy 2010-3: Customer Confidentiality, number of people in the room and remote, 133 total. Number in favor, five; number against, 70. This will be provided to the AC for their consideration. Thank you, everyone. We'll now move on to the Regional PDP Report with Einar Bohlin.
Einar Bohlin: Thank you, John. This is to let you know there's five RIRs in the world, and this is to let you know what's going on at the other four.
So I do -- every ARIN meeting I take a snapshot and look and see totals of what's being discussed. So right now the green bars show that in the second quarter of 2010 there's about 35 proposals on different topics. The bulk of discussion policy proposal-wise is on the topic of IPv4, followed by v6, and then you have directory services, ASNs and other pop up now and then.
The bottom of this slide shows how many ARIN proposals are part of that total. So, for example, with IPv4, there are about 18 different proposals on the topic of IPv4. Four proposals here at this meeting are ARIN proposals, which is kind of interesting. IPv4 is still a much discussed topic, of course.
So these slides, ordinarily they would show -- actually, this meeting is kind of unique, because we have eight draft policies and there aren't really anything like them at any of the other RIRs. So it's intentionally blank. As is the second slide, except for the case of APNIC, which actually did have something similar to 2010-3 years ago, actually, and adopted it.
So what are the other RIRs actually discussing? We saw that there's a lot of different discussions about IPv4. So those discussions -- there's several discussions about the topic of the last /8 and what to do with it. We have I think we're down to 20 /8s right now, and there's that policy when there's five left, each RIR gets one. So there's discussion about what to do with that last /8. The topic of transfers is being discussed.
APNIC is moving forward with a policy to do away with allowing customers to come in and make exchanges for prefixes for the sake of aggregation.
And the RIPE NCC is talking about -- they're enshrining -- they're making clear they can do the audit historical allocations.
And on the topic of IPv6, looks like it's a hot topic in the LACNIC region. These are -- these should be familiar to you guys. They're proposals that came to our region and moved forward.
Removing the routing requirement from IPv6 ISP allocations, multiple discrete networks for v6, and micro assignments for internal infrastructure. That's the last one where you can get a small -- you can get your /32, but you can also get, for example, a /48 for internal infrastructure as an ISP.
ASNs is a topic at APNIC. I think that was to ensure efficient use of legacy ASNs. Directory services is pretty obvious. And AFRINIC is discussing their PDP.
I've got references here. You can find the exact proposal numbers and names if you're interested. You can -- you're free to participate in the other regions' public policy processes, just like you are -- just like they are here at ARIN.
And the final document on there is the policy comparison overview, which I always try to plug. It's if you want to know what the minimum IPv6 allocation policy is for ISPs or end users at all the different RIRs, you can go to this document and get that information very quickly.
And that's it. Thank you.
John Curran: Thank you. Any questions for Einar? Thank you.
Leslie Nobile: Good morning, everyone. These are the joint statistics of all of the five RIRs, and we prepare these and show them in a side-by-side format. We update them quarterly. This data is current as of March 31st, 2010. The first slide looks at the global IPv4 address pool at this point.
So if you're looking at -- from the top on the left slice there, it says Central Registry. And there were 91 /8s issued prior to the establishment of the RIRs, and that's what we call the Central Registry. This address space was handed out under U.S. government contract in the early days of the Internet. As expected, most of that space, most of those 91 /8s, were issued in the ARIN region and, in particular, in the United States.
Moving to the right, the green, there's 35 /8s not available for the IANA to issue to the RIRs.
That space is in use currently by the technical community, and the designators are right there. You can see what they're in use for; I won't read through that.
If you move below the green pie into the gray, you'll see that IANA reserved space says there are 22 /8s left. Actually, as Einar just mentioned, we're down to 20. APNIC recently got two /8s, so there are 20 /8s left in the entire pool.
And moving into the blue slice, you see the RIRs combined have 108 /8s from the IANA that we're currently administering. And the division of that is below: APNIC has 36; RIPE has 30 /8s, LACNIC, six; AFRINIC, three; and ARIN, 33.
So if we're looking at IPv4 address space that we've issued, we've gone back as far as 1999. And this is just like the ten-year picture here. And there's some growth up and down.
The thing to take away from this one is that much of the growth in IPv4 is currently in the APNIC region. And that would be the yellow bar.
The thing that's interesting about 2010, this first quarter -- well, actually, APNIC issued, what, I guess, close to two /8s just within the first quarter of 2010. So the growth is definitely happening in that region.
But the other thing to note, if you're looking at the blue and the red bars there, ARIN is actually in the blue, and ARIN issued less address space this first quarter than LACNIC. So LACNIC, RIPE, and APNIC all issued more before than ARIN did this particular quarter.
This is just the cumulative total of that address space, what we've issued to our customers in total in v4 since 1999. RIPE has issued a little over 26 /8s; ARIN, a little over 23; LACNIC, a little over four; AFRINIC, 1.31; and APNIC, a little over 32 /8s in total.
ASN assignments. Again, just kind of up and down. Currently RIPE is issuing more Autonomous System numbers than any other RIRs, the bar in green. And this just shows the cumulative total in the past roughly ten years, ARIN and RIPE issuing more ASNs than any of the other RIRs.
This is the IPv6 address space, it shows the pool of addresses, and that's a /0. That's the entire space. A /3 is currently carved out for global unicast. There's 512 /12s in the entire space in the yellow pie. And that's the IANA reserve. That's what IANA is issuing to the RIRs.
And the red circle shows a single /12. And I've labeled it miscellaneous. There's lots of different uses. 6 to 4 space, some RFC space, and a lot of /23s that the RIRs were getting from the IANA in the early days before this global policy was put into effect in October of 2006.
So if you look up, the RIRs each received one /12 in accordance with the global policy. And that's our allocations right there.
And this looks at the past roughly ten years of IPv6 allocations from the RIRs to their customers, to ISPs and LIRs. And as you can see, the green bar, RIPE NCC has been issuing more IPv6 address space than any of the other RIRs.
But, again, the thing to note in this first quarter, which is really interesting to me, is APNIC, in the yellow, issued 186 -- made 186 IPv6 allocations in the first quarter of 2010. That is more allocations than they've ever made in a single year.
So in three months they've issued more v6 space than they ever have in an entire year, which I found interesting. So v6 growth is obviously occurring back in the APNIC region again.
So this slide has total allocations made by the RIRs, cumulative totals on the left. And in the right it's the total number of /32s. These numbers don't agree at all, of course, because single allocations -- you can see RIPE a little over 1,900; ARIN, 800; APNIC, 800; LACNIC, almost 300; and AFRINIC, 66.
But all of us -- most of, actually, larger RIRs are issuing much more than the minimum allocation size, which is a /32, so we're issuing quite a few /32s, but of course the allocations are much less than the total number of 32s.
These are the links to the RIR stats, the NRO website, the RIR's websites, all have FTP stats, and then the raw data, the historical data is on the IANA and ICANN websites. So those are the links, and they'll be up later if anyone is interested. And that's all I have.
Geoff Huston: Geoff Huston from APNIC. I feel I should explain the IPv6 allocation jump. There was one policy that Einar didn't actually mention that came through in our August meeting last year where we were exhorted by our policy to make IPv6 allocations easier, and in particular for those who already filled IPv4 allocations for us.
So over the last few months we've worked pretty hard to do a single one click; that if you already have an allocation of v4 from APNIC, you can immediately get a corresponding v6 allocation. And that has been the major driver in terms of getting take-out.
So it was largely a membership-based initiative that said, look, guys, you've really got to cut the crap here. And we looked at all the other mechanisms, thought the easiest way to do it is to simply get rid of a fair deal of the processing. You already have v4 addresses, you get v6. And the stats then show the result of that.
The other thing I can't quite understand is actually reflecting LACNIC in that slide there.
Leslie Nobile: Is that one before, this one?
Geoff Huston: /32s. When I look at it, I see this rather large assignment from LACNIC that went over to Brazil that's not reflected in your stats. I'm just not quite sure what's going on. Maybe Raul has some more details there. But LACNIC did do a large block.
Leslie Nobile: I think the way LACNIC is counting their allocations to the two NIRs -- it's interesting. Brazil, they don't count the large allocation, but then Brazil shows their allocations individually in their own FTP stats, I think. Okay, Raul, thank you for saving me.
Geoff Huston: I'm looking for the Brazil stats too, and I can't find them.
John Curran: Raul.
Raúl Echeberría: Hi. This is Raúl Echeberría from LACNIC. I think you could reflect the information fairly in both ways. Because what we do is we just mark part of our space for being used by the two NIRs, Mexican and Brazilian. The difference is that the Mexican NIR use our own system. And the Brazilian has their own. We are in the process of changing that because we are implementing an innovative solution based on EPP that will be available later this year.
And so this information will not be shown in the future in that way. So the Brazilian -- you will see only the space that is being reallocated.
So if you want to show that the Brazilian has received larger block of IPv6, it's not false at all. So you can do that. If you want to show exactly what the Brazilians are located inside of Brazil, it's also true. So you can show the information in both ways. I think it will be fixed next year.
John Curran: Okay. Thank you. Microphones remain open.
Marla Azinger: I have a question.
John Curran: Yes, down at the end.
Marla Azinger: It's for Geoff, though, for the RIPE region. I'm aware that you're allocating address space for 6rd and /28s have been assigned for that. I'm curious, do you know the quantity of address space that's been handed out for 6rd at that size?
Leslie Nobile: For APNIC?
Marla Azinger: Sorry. Yes. Did I say something else? I'm so sorry.
Geoff Huston: You're asking me what's happening in RIPE --
Marla Azinger: No, I'm asking -- sorry. I apologize. But do you know the numbers for what 6rd assignments have been done?
Geoff Huston: The only one I'm really aware of, of course, is free.fr, which has been extraordinarily successful, but I'm actually unaware of particular allocations.
Part of the issue with 6rd was that it was meant to fit within an existing provider allocation. So I didn't think it actually had to do special allocations just to do a 6rd-style technology. It was meant to be a part of an existing provider-based allocation.
Marla Azinger: In the other regions it works that way, yes. With our policy it's a little different. But I was just curious how much -- don't worry about it. I was just curious if you knew offhand how much went to it.
John Curran: Any other questions on the Resource Status Report? Thank you, Leslie.
Aaron Hughes: This is Aaron Hughes. This is a presentation that is a little different than the normal presentation you see at ARIN. It's best current practices and part of where they fit.
So I gave part of this presentation at the last NANOG, so for those of you that were at the last NANOG, forgive the first dozen slides or so. There is an update, so please pay attention after we get through those.
So, first, what's a BCP? Today, as many of you know, when you're trying to solve a problem or implement a best current practice, dear Google is usually your friend. Sometimes it's peers found on IRC. Sometimes you have a buddy in conference or online that you know is a subject matter expert.
And if you're really feeling up for a challenge, you might actually go through historical presentations on the ARIN or NANOG websites.
Basically they're almost nonexistent today.
So what do we want to do about it? The idea was to build a repository of living BCPs, ask subject matter experts to write some documents on topics, share them with the community, and then keep them alive, current, accurate.
Why would we want to do this? I and others in the community believe that something like this is needed. Hopefully the result is once this is established, things start to get better. We get less errors in the implementations, more real-world information, and hopefully we can start to fix some of the basic things that we've been trying to fix for many, many years: filtering, subnetting, security, IRR data. Just a better Internet in general.
So, as an example, I would decide to write a document for a best current practice for subnetting v6 /32 as an ISP. And all of this in the BCP model is 8020. So it's for making sure it's the best current practice for the 80 percent of the Internet that follows a general best current practice as opposed to the 20 percent that are doing their own thing. They know what they're doing; they don't need these documents. Hopefully they're full of subject matter experts that will help write them.
I would submit the BCP to the site, the community could then either accept or reject it. People would read it, and if they know something better, they'd update it, making it live and making it better.
Then someone who otherwise knows better builds a better network or an operational practice. And I've heard this a lot actually in this room and private discussions on the side: That people want to know how to do things the best, and documentation like this is just simply not available.
So where does this live. This is where things get a little interesting. So NANOG is probably not interested. They cater to the audience that are the regulars, and that is -- the majority of that is that 20 percent, not the 80 percent.
And ARIN says, well, their official party line is they'll do anything the community says they should do, which could include hosting BCPs. But it's a little bit of scope creep and might take a lot of time.
IETF, on the other hand, does have a BCP process. Doesn't quite work well for living documents and might take a lot more time.
So the alternative choice is a third party, another organization. So who? Well, this started as a presentation I gave on v6 implementation for ISPs. Cathy Aronson commented something about that sounds like a good start for a BCP. Had a dinner with Lee Howard and a few other people over dinner, which included a NANOG PC member, NAC member, a BoT member, a couple people from the community and a few subject matter experts.
The idea was to keep it as neutral as possible. We agreed at the end of that that we would take some steps to try and present this to the community, and the next big step being to have a BoF to hammer out all the details how to do this as a larger audience.
Okay. So I've already done this at NANOG. I'll do this here as well. Show of hands of people in this community who are in favor of this kind of activity.
John Curran: If you're in favor, please raise your hand.
Aaron Hughes: Very, very nice to see. So get off the stage, Aaron. If you're in favor of not -- of stopping these activities, please feel free to raise your hand.
Okay. That's what I was hoping for.
John Curran: Okay. Anyone interested in this, find Aaron.
Scott Bradner: John. Just a question, Aaron, on what's the review process.
Aaron Hughes: Let me continue, and then we'll go forward.
So next steps. This was from the last presentation. At NANOG I did a presentation. The next step was to find a BoF. We were -- so we could work out a lot of the details, like is there a pending versus accepted living document distinction, draft versus live, who can post BCPs, is there a minimum requirement for the poster of the doc, how does the document move from draft to live status, all kinds of stuff. These details are not hammered out.
Between now and then the idea was to launch an ORG, wherever that lives, publish a document to test the process and validate the software to make sure that this can work in scale, and dive into the details of the process.
So I haven't thought of everything, but I've had some pretty good discussion with a lot of people in the community, and I think we have a good idea to start the base for this.
So since then I have presented this at NANOG48, and I had a similar ratio of people with hands in the crowd, which was very nice to see. We kicked off a BCP discussion list, and I launched -- on my company I launched a 6connect.org site until we have a BoF where we can decide where this should live. But it's a placeholder. We've done a bunch of software testing to figure out what can support living documents and we've submitted and BoF has been accepted for NANOG49.
I've written a draft for BCP subnetting for /32s for ISPs, and specifically picked this topic because it's relevant in both the NANOG and the ARIN communities.
So the next steps from here. We're looking to do a closed launch for testing on the BCP discuss list where I'll launch the site with a few different copies of software on the same document to try and interact with it to make sure we can validate the process and prepare for the BoF in NANOG49.
If anybody is interested in helping me, please reach out, come and find me or subscribe to the BCP Discuss List.
Okay. The next piece is discuss with ARIN bridging the gap. So this room. This is what this is about for you. Here's some outstanding questions that are a little difficult. Where do you want the updates for this kind of conversation? Do you want to talk about this anymore in these kind of meetings, or should we move it to the BCP list?
So the options are we can host this kind of thing at ARIN, we can host it at NANOG, we can host them on the BCP discuss list. I can do this once a year when we have a joint meeting, or I can keep updating on all meetings in little presentations like this.
A somewhat relevant point now is maybe wait for NANOG futures/NANOG merit split to hammer out some of these details. And another is get off the stage, put this on the list.
Marla Azinger: Best kept practice documentation is definitely needed. What I don't like about this is creating yet another organization. What I would really like to see happen is charter changes to NANOG really and have it there. And then also make sure that IETF has the BCPs where they need to be at that level, too, and there is more of a movement at IETF to get BCPs done. I'm involved with it myself.
And it's just a matter of getting people to do the work. There are means for it getting done. So, yes, I support getting BCPs, but I really would like to stick with organizations that already exist. We don't -- I would hate to have to keep up with yet a third one.
Aaron Hughes: I completely agree with that. And to be a little personal, part of this I put up on my application for Board of Trustees here. I made my intents clear. And it didn't make that and nobody else seemed to want to be involved in this kind of thing.
So this is what's been happening. It came out as a separate -- a few people personally trying to help get this done and bring it to a community in a way that wasn't obstructing any other current process so that this didn't slow down.
Marla Azinger: That's kind of a separate topic. So, yeah, that is personal, I agree, so keep it on topic. We do have organizations where this stuff can be done already and where charters, we can work within. And NANOG is undergoing changes right now. So this might be an excellent time to really push for that there.
Aaron Hughes: If anybody wants to get involved with this, show up at the BoF NANOG49. I'll be happy to go any direction. They can live in any of these organizations. I really don't care; I just want to see some BCPs be released and start working on them.
John Curran: Center rear mic.
Lee Howard: Lee Howard, ARIN Board and interested community member.
In response to Marla, I've spoken to the area directors of IETF operations area and suggested -- and talked about some of this work and that this would be an interesting area for them to get involved in.
One of my personal concerns as we've been discussing these ideas has been that the best practice may be different in different regions of the world. And IETF is not equipped to handle that kind of global differentiation, I think.
So the best practice for North America -- anyway, I think it comes down to, yes, a NANOG ARIN scope organization is perfect. Again, I don't care where it goes. I think it's work that needs to be done. And, yes, I also would like to give them their due. The opposite of – Copana and Romanescu are very positive and definitely want to help, too.
John Curran: Okay. Far left mic.
Tony Hain: Tony Hain, Cisco. I actually do support the work behind this and I think it's needed. But I actually had the same concern about regional differences and what is considered best practice. I also am a bit concerned that a piece of what comes out of this ends up coming back to ARIN as policy.
In particular, as I think about -- I haven't read your discussion about best practice for /32s, but I can imagine some of the discussion for how that gets subnetted comes back into a policy discussion here.
So I don't want it to get too divorced from ARIN, because I think, from my perspective, almost nobody in this room should be getting /32s. That's the mom-and-pop starter kit, and those are the people that aren't here.
So that's the level of, yes, the 80 percent needs this document and needs to think about that. We need to make sure that the guidance that's in there is for somebody who really is just starting out, and that the best practice for the people who are just looking for what's everybody else doing is looking a little bit larger scope than that, and I don't want to see ARIN saying everybody gets a /32, because that's almost every place I go, somebody says there's not enough subnets in the /32, what am I going to do? I say go get a bigger block.
It's the level of education and how that gets tied together, I'm a bit concerned that that gets wrapped correctly.
Aaron Hughes: I completely agree with you and completely agree with keeping it for the intent of the 80 percent model. I realize that there's a gray area between policy and guidance, and ARIN has the same issue. Right? There's a wiki up at the ARIN site that are documents that when they are posted are fairly accurate and fairly reasonable guidelines, and things change and people don't up them. So the documents become stale.
It's much like the problem we have today with presentations. They're only relevant for generally the meeting or two that you're there, and then they become stale. And it's very hard for someone new in this industry to read through all of that data and figure out what pieces they should take out of it and consider valid and current and, generally speaking, a best practice.
And I fully intend to make sure that that is relayed as a common message throughout all these conversations.
John Curran: I'm going to be closing the mics shortly. If you need to comment on this, get to a microphone. Center front.
David Farmer: David Farmer, University of Minnesota, ARIN AC. I think this is an excellent idea. I think if it can be made to happen, focusing in on NANOG to do that is probably the right place.
Making sure that there's still some ties to ARIN and maybe even a little support from ARIN to ensure those ties might be a good way to deal with it.
And then I do want to encourage that I think developing regionally seems to make sense. But then we should also take what the next step is. Just like we sort of developed global policy from the ground up regionally and then figure out what goes global.
As we develop these regional best practices, some of them might go global, and then those should probably go to the IETF to get an IETF stamp that says, yeah, this is a good global policy.
John Curran: Just a few thoughts.
Aaron Hughes: Again, I agree with that. The issue that I mentioned in one of these slides is that NANOG honestly caters towards their regular attendees. There's a new set of attendees every NANOG that's about one-third of the attendees, but they don't come back. They're missing something that provides an education from getting where they are to participating in that, the meeting that it is today.
That may change. Someday it may actually appeal towards newer people in the industry. But today it doesn't.
David Farmer: I think that's something for NANOG to think about. Because if all -- eventually all the normal people that go there will have all been through the program committee and will all be burnt out, and the long-term longevity of the organization requires new people, so you should think about the new people.
Aaron Hughes: This is a great topic of conversation in the BoF. And the other question is, you know, the people that come to this meeting that don't come to NANOG's, how do you want to participate in this? Is the list enough? Do we need to have another separate sort of BoF for these kind of discussions to be hashed at as well.
John Curran: Closing the microphones on the main floor. Don't join the queues on the main floor. Remote participants, this is your 60-second warning to start typing. You'll shortly be closed as well.
Center rear mic.
Martin Hannigan: Martin Hannigan, the Iceland guy. Sorry about those volcanoes.
Good work, Aaron. I think this is great. The only thing I would suggest that you might want to consider is why get involved in all these politics in the first place. Why not follow the illustrious history of the Internet where anybody in the world can set up a website and a mailing list and do their own thing without being encumbered by the politics of large groups of people. Thanks.
Aaron Hughes: Noted. It's yours.
John Curran: Thank you, Aaron.
Okay. Very good. No remote participant comments, so that will end that presentation. We're just a touch over time, but that's okay, it's lunch. You can eat two bites quicker.
I would like to tell you lunch is now served. We're going to resume back here at 1:30. Important things: AC topic tables. When you go to lunch, look at the table you're seated at. There will be a sign and that sign will have information about the topics being discussed at that table. The AC members who will be joining you at that table are interested in those items. If you're interested in talking about a particular topic, you can choose a table. You don't have to, but certainly it will make for more interesting discussion.
Security. Take your valuables with you. This room is not locked. You must take your valuables with you.
One other little thing. If you go outside, you'll see the ARIN booth is set up. The ARIN booth has -- on the advertising copy, there's a gentleman there, well-dressed dapper gentleman with some headgear. We want to name him. Name that dude. So if you go by, you'll see a big bowl. You can name the gentleman who shows up on our ad copy work. Just put your name, put a suggestion, and throw it in the bowl.
Thank you very much. We'll see you all here at 1:30.
[Noon recess at 12:06]
Geoff Huston: Good afternoon, everyone. I'm Geoff Huston. I'm with APNIC. And, yes, as John said, part of the issue around why address distribution policies are built and maintained as the NRO is to make addresses usable on a network. And the implication is that what makes addresses usable on the network is their ability to be routed. So if you want to understand how successful we've been and what issues are coming up, then what you should be looking at is the routing table. So to save you the bother, I've looked at it for you, and these are the answers.
So, firstly, let's sort of understand a little bit about where this is situated in terms of important factors that might kill you in the next few hours. And I love this quote. This was October 2006. And this was from an IAB workshop on inter-domain routing. And at the time it said: Routing scalability is the most important problem facing the Internet. Not v6. Not security. Not anything else. It was going to be routing scalability.
I suspect that was a little bit of hyperbole, going a little over the top with that statement. I think there are many more important problems. But, nevertheless, routing is important. But to the extent that it is that important a problem that it requires some massive new bit of technology, I'd like to look at -- and in particular look at the data that we have available. We have a lot of data about BGP, and there are a number of ways that folk have been studying it.
Both the RIPE NCC and the University of Oregon and Cisco and Route Views have done an amazing amount of work in assembling a truly massive amount of data about BGP, collecting the updates from an enormous number of peering sessions over an astonishingly large number of years. That's one way of doing things, just click the universe and then figure out what's inside it.
The other way of doing things is to try and just perturb the environment in a way that you understand and then look at the outcomes of that. Nudge it a bit and see where the echoes fly.
And there's been a fair deal of work with beacons, Marley Mau and that crew with Lixia at UCLA. There's been work that and Lorenzo Colletti did as part of his Ph.D. in manipulating ASs and AS sets, and AS path poisoning. And there's work that was originally done I think by Peter Boothe at the University of Oregon on bogon detection and triangulation. And the whole idea is if you simply disturb routing a little bit and understand who saw it and how they reacted, you can actually infer an awful lot of information about BGP.
And the last way is really simpleminded, incredibly simple. You set up a listener and listen. And guess what I did? I took the easiest way out I possibly could find and just set up a single listener and just listened.
What did I find? Firstly, I've been listening since 2007 on this particular AS, and it's entirely passive. It doesn't do anything. It doesn't advertise anything, it doesn't perturb. It just listens. It's a Quagga platform. It runs dual stack. It just archives everything it finds. And it's all there at that URL.
So how did BGP do? You've all been around the Internet for ages. You all know the bottom-left top-right kind of graph. Yeah, bottom-left top-right. This particular one is the count of the number of prefixes in the inter-domain routing zone, the Default-Free Zone. And over -- well, it's not quite 12 months, I've extended it to a few days ago, it went from 285,000 to 320,000 entries in around 15 months. Well done, everyone. Excellent job. Thank you.
How about the routed number of addresses? You went from 118 /8s to 132 /8s. Interesting we're running out of v4 but less than half -- or, sorry, just on half is only visible in the routing space. Whatever you're doing with the rest of the space I hope you're enjoying it, but it must be private fun, because the rest of us can't see it.
Those big steps in the amount of addresses on the advertising space, they're actually people flapping a /8. Now, I claim all of the flaps over there in 2010. That was APNIC's fault and we're terribly sorry. But someone else was playing around with /8's earlier in the year, around July and August. Own up, or we'll have to find you anyway. I don't know who does this, but people do flap /8s. That's the amount of routed space, bottom-left top-right.
This one's amazing. It's amazing because it's linear. The number of autonomous systems grew from a little under 30- -- sorry, 30,400 to around 34,000 over 15 months. Every day a few more got added. It's like there's two or three people in the world whose job it is to put new ASs on the Internet, and it's their job and every day they put another two or three -- they put 12 on the Internet every day, 12 more ASs. Day, night, every week, they just put 12 more on the Internet. Astonishingly stable. It's really stable. If anyone, you know, ever talked about the global financial crisis, those guys weren't listening.
Just didn't move a bit. It's astonishingly linear.
So, anyway, how much did network grow last year? It grew by, by and large, about 10 percent. So the number of prefixes up by 10 percent. Interestingly, this whole thing about aggregation and more specifics, we're no smarter and we're no dumber. The number of non-more specifics, the roots, grew by around 12 percent, and the number of more specific advertisements grew by 9 percent.
We're not getting any clever. In other words, the folks who were going take a block and deaggregate it are still doing it.
The amount of addresses up by 9 percent, amount of ASs up by 10. Interestingly -- actually, I think that is interesting. The amount of transit ASs, the folk in the middle who were carrying other people's traffic, grew by 10 percent as well. Which I find a little bit curious. It should have grown by less.
That's lower than it used to be by 10 percent. Used to be 12 to 15 percent. So why is it lower? Partially because there was a global financial crisis and the amount of money entering the network in terms of investment in infrastructure slowed down slightly.
And some parts of the world it slowed down more dramatically than others, so the overall was a slight reduction. But equally importantly, this industry is morphing under your eyes. This is no longer lots of small ISPs being vibrantly competitive. If you actually analyze where the address space went, over 2009 25 percent of the amount of IPv4 space went to 16 entities. One percent of all allocations took up 50 percent of all the address space. This industry is showing all the classic signs of economies of scale. It's bulking up. A very small number of very, very large players. Those players don't generally mark up in the routing system. So part of the reason why the routing system isn't growing as large as it used to be is, oddly enough, diversity in supply is slowing down. As the industry bulks up, there's less diversity in supply.
So it's actually an indicator of increasing market dominance. What's going on is pretty typical in any volume-based industry. So that's largely v4 as we knew it. But, you know, there's also v6 as well. And this is kind of a different kind of bottom-left top-right, because when you try and draw a line across it, it doesn't quite fit. It's sort of bendier.
In other words, the v6 network, although there's not a lot of it, is growing faster than linear, even in this 15-month period. Number prefixes from 1,600 to 2,800. Well done, everyone. The amount of address space is truly weird. This is a linear scale, and this is a few -- just massive leaks.
What I did do, by the way, is eliminate the one fantastic routing leak. Someone leaked a /3. For six weeks. And no one noticed for five of them. That was across December and January. I took that out, because otherwise it would just be this dead flat line at the bottom. This massive peak for a few weeks, and then down to nothing again.
Removing that gives you that kind of funny graph. There's the AS count. Interestingly, you know, there are fewer ASs in total. Grew from 1,200 to 2,000 across that period, but it's not linear. It's actually growing faster than linear. So the growth stats for v6 are dramatically different. By and large, the numbers are around 50 percent.
In other words, whatever v6 was, and they're relatively small numbers, the growth rate is a massive amount larger than v4. It's actually moving quite quickly. So that's good. By and large, I'd guess it's around 50 percent. If this increases the way it's going, then the network will be completely v6 in about 25 years.
My point is, even though you can say it's growing faster than v4, it needs to grow even faster than this if you're ever going to sort of make a reasonable dent in v4 in the next couple of years. It's not increasing as much as it should.
So that's the way routing looked. But where is it heading? So folk keep on saying that 300,000 entries today, 400,000 tomorrow, a million the day after, all my routers are going to die in three weeks' time. So let's actually apply some math to this problem to understand exactly what it's going to look like in the future assuming that tomorrow is a lot like yesterday. So you smooth the data. Take the first-order differential, do all the squares and so on.
So this is the last six years of the BGP table. 120,000 entries up to 320,000, and that's the first order differential. I want to stop there for a second and sort of look at what happened to the network in 2008.
Because from 2004 to 2008, we were adding 60 entries a day, 80 entries a day, 100 entries a day. And at the start of 2008 someone got very busy and added 200 new entries in one day. And then all of a sudden they decided, oops, and then the network stopped growing at the same rate. And across 2008 and 2009, the speed of increase dropped a lot. And across 2009, instead of doing 100 new entries a day we're doing around 60 to 70 to 80. And the last few months we've been right down at 30.
Now, the v4 network isn't growing as fast as it was growing. The downgrade rates have stopped. But I can still do maps on it. You can still do a quadratic fit. There's the equation. And like any other equation, you can push it forward and the blue line looks a little bit like the red line, doesn't it?
You need to say yes. The blue line looks a lot like the red line. So if you push that forward, it's possible to sort of say, well, this is what it's going to look like in the Default-Free Zone over the next few years. By the end of this year, 350,000 entries. By the end of 2011, start of 2012, 391,000 entries. And normally I meant to blithely say after that, a rate of 400,000 and 500,000 after that. The problem is that, of course, v4 exhaustion kind of hits the wall at about then, and all of a sudden all bets are off.
Because as soon as the current supply systems of addressing, particularly in v4, stop I have no idea what this industry is going to do. I have no idea, and neither do you, how much address space is going to get fragmented as it hits the routing table.
Whether all of a sudden the dynamics of the increase in the routing table will vary a lot, I suspect they will. So the furthest I could look forward to with confidence is late 2011 and say we'll be up to about 400,000 entries in the routing table, but beyond that I have not got a clue. It just goes nonlinear.
You can do the same exercise for v6, by the way. So you take a long window of v6, do the growth rates, three entries a day. Work harder, everyone. Three is not 60. Do the extrapolation forward in a quadratic, match it up. If you're really lucky, you'll get to 8,000 entries by 2014.
Overall, all I can say is by the time we get to around 104,000 entries all bets are off. I have no idea thereafter what kind of a routing system we're going to look like.
But what I can say is that there's the low projections three years out. By the time we hit v4 exhaustion, it is just completely not obvious how much lower it's going to be. Is that a problem? You know, if you're buying a router today, you'd obviously like it to work in the field for about five years.
So the real questions you should be asking yourself is, you know, what's the service life of your installed equipment, what's the price performance curve you're looking at, particularly for ASICs and routing engines, and what's the growth factor in FIB size.
By and large the available data that we have in industry tends to suggest as long as the table doesn't grow by more than 20 percent per year, the unit cost of routing remains constant.
In other words, it's not Moore's law because memory is a different law. And the cost of memory in particular. Fast memory. But a growth factor around 20 percent is about the upper bound of what will remain cost effective in routing. So, so far we're around 10 percent. You're doing just fine. Routing is not going to balloon as a cost or become a problem. But, quite frankly, in three years' time, I have no idea. I have absolutely no idea what the margin of uncertainty is.
So on the size of the routing table, there's nothing obvious in today's dynamics that tend to suggest we have a problem. What we're doing as an industry is working as an industry today. And that will continue to work as far as I can see until address scarcity becomes a factor in your behavior. And as soon as it becomes a factor in the way you behave, I have no idea how you're going to behave, I'm sorry. I suspect you don't either. And I don't know after three years what that means in terms of routing.
So that's the one problem. Other folk keep on saying it's not the size of the table, it's the amount of activity. It's what you do with it that really counts. It's the amount of updates every day that turns your CPU into mush.
So the other thing I've looked at over 2009 was the amount of updates that happen in BGP. And there's the plot. Most days we're pretty quiet except some days, and one day in particular, was amazingly bad. Why? I had a problem. I kept on resetting my router on that particular day. So let's remove local noise, the things that I did to upset BGP to cause the entire routing table to come at me. And look at the rest of the days. This is for 12 months. Big hint. It's not bottom-left top-right. That's bizarre. The number of updates every day was around 100,000 for the year.
Something's going wrong here as far as I can tell. You know, I drive my car to work. You know, naughty me, and over the years there are more cars on the road. You might have noticed this, too. It's an odd phenomenon. As there are more cars on the road, my trip to work gets slower. It's called congestion.
But in BGP, we kept on adding these entries to the routing table. But the amount of activity in BGP has remained constant. Something very strange is going on there. So let's look at this instead of over one year, let's go back to 2005. Even more bizarre. The network's grown from a much smaller number of entries to 300,000. But the number of updates per day has been around 100,000.
That's not right. That is just not right. Something else is going on here. Project that forward, and no matter how far you want to go, the same projection technique says life isn't moving here. The number of updates per day is approximately the same. 100,000. Something very strange is going on. So then looked at the withdrawals that happen every day, same technique. And, again, over an extended period, it just doesn't look very dynamic.
So whatever's going on in BGP, it's constant. It doesn't move. The same amount of activity has again and again every day. So the obvious question is: Is my data collection completely staffed or is there something going on in BGP that is entirely nonintuitive? In other words, why does the amount of dynamic behavior in BGP appear to be so amazingly flat?
So this is the one that I kind of like. Instead of looking at the number of updates, I count the number of prefixes that are the subject of updates. So as you see some day I get a complete table reset, might even happen a few times. Along that day I see every entry in the routing table. So that's the line at the top. As the routing table grew, on the days where I do a local reset, I get the complete table fed back at me. But what about those days when it didn't happen, the ones at the bottom.
That's bizarre, because it's not a certain percent of the routing table that is busy, it's a certain number and has been for over three years. In other words, over the last thousand days we've increased the amount of traffic on the road by 40 percent. 225,000 entries up to 320,000. But on a day when I'm not having a bad hair day locally and I'm seeing the rest of the planet, the rest of the planet only sends me around 20,000 entries, constant. Every day.
This is something weird. The amount of instability out there in dynamic updates isn't related to the size of the table. This isn't some sort of background radiation that's X percent of BGP. It's a fixed population. It's not the same, guys, by the way. They do change. But it's the same number every day.
I'm now kind of interested as to what's routing instability related to. So let's talk about BGP. It's kind of an old routing technology. It's a distance vector algorithm. And like any distance vector algorithm, it likes to chat a lot to itself before it figures out what a best path is.
So typically what you find is that dynamic behavior tends to cluster up. I think I have an example here. This is a routing advertisement coming from Moscow. It's a RIPE routing beacon, and this is a withdrawal. So I saw a stable path of length four, and then when it got withdrawn at source, I saw a sequence of updates with increasingly longer paths until eventually I saw a withdrawal. What I actually saw was a tight cluster of five events across 150 seconds. One event at source, five events near me.
So BGP is like a little bit of a line amplifier, and, theoretically, the bigger the network, the more entries, the more it will amplify. Theoretically, as the network gets larger, BGP heads into meltdown. Oddly enough, that's not happening.
So let's have a look a little bit deeper. So now what I would like to look at inside all those updates I saw is classify them into two kinds, because there are two different kinds of activity. One is updates with the same prefix is refined a number of times quickly until it gets to a stable point, a convergence sequence, where it's sort of trying to get close to the answer and then it zeros in on the answer. And the other ones are isolated events, single events. There's not much I can do to the single events, so I'll ignore them and just focus just on those things that require progressive refinement to get to an answer.
So how many of these sequences do I see a day? I saw 20,000 prefixes a day, but some prefixes have two or three sequences in a day. How many sequences do I see every day for the last, oh, three and a half years? Interestingly, I see about 30,000. So that, too, is a stable number. So all of these sequences tend to be between 20- and 40,000 and haven't moved for years.
How long does it take for a prefix to converge? How long do those sequences run for on average? There's a discontinuity there that happened in 2008 that I can't explain. But over the longer term, it takes exactly 72.3 seconds for your update to converge across the network and has done for years.
Weird. The network is growing bigger. The network theoretically is sort of larger, but the amount of time to converge has actually remained pretty constant. The average convergence time I see in these sequences remains the same. Takes around 70 seconds. So that's basically between two and three advertisement intervals, constant for over two years. So as the network expands, a distance vector algorithm should get longer. It's not. It's actually staying the same time. Now, that's contradictory, as far as I can see.
How many updates do I see in a sequence? I see around 2.7. Have done for years. So the amount of chattiness in the network is astonishingly constant. So as far as I can see, what we've done, when we've added all these new entrants to the network, we've added a lot, is the network in terms of distance from A to B has actually remained constant. And what we've done is increased the density of the network, not its diameter.
So as far as I can see, there's basically -- it's something else going on about the way in which BGP is converging. I kind of like this one, because this is a graph that you'd either say shows Cisco's dominance of the inter-domain routing industry or shows something very funny about the way in which we design protocols. Cisco has used a 28.5 average second advertisement interval.
And when you actually track the amount of time it takes in seconds for any sequence to reach convergence and you distribute that, what you actually find are these sharp peaks that happen at 28.5 second intervals. That's a logarithmic scale on the left to amplify it. But what you tend to see is that there are really strong peaks inside the convergence time in BGP. What we've done is designed a system deliberately that rings like a bell at a harmonic frequency of 28.5 seconds. This low hum of BGP.
But what I can then do, as well as look at the time, is look at the number of updates. Same thing. How many convergent intervals took one update, took two updates, three updates. How many in each particular level. Again, plotted as a log function. And then what I want to do is compare that to the distribution of pre-pended AS paths. Now, I deliberately included pre-pending because that's what you guys wanted in your routing policy.
Those two graphs are actually pretty isomorphic for about the first 10 or 12 intervals. In other words, what it's showing is that for about 98.66 percent of all updates it's related to the AS path length. In other words, how far you are away from an update actually determines how many updates you see.
There's a very small number of events that are persistently unstable. They're beyond help. There's nothing you or I can do about them. They just like to update continuously. But everything else appears fundamentally related to the underlying topology of the Internet.
And the real interesting graph is this one. In 1998 how many entries were there in the BGP routing table? Come on, quick quiz.
Unidentified Speaker: '98?
Unidentified Speaker: 25,000?
Unidentified Speaker: 43,000.
Geoff Huston: 43,000 is about the right answer. There are 320,000 entries now. Yet the AS path length has remained constant. In other words, what we've done is added another 270,000 entries into BGP. We've added another 30,000-odd ASs, yet we've kept the diameter, the average length of the network at around 3.8 from where I sit. Where you sit it might be a subtly different number, but it's been the same number for years.
So as far as I can see, convergence is actually about the topology of the network, the average AS path length. And what's actually going on is that as long as we can keep that AS path length constant, oddly enough BGP remains astonishingly well behaved. You can actually double the density and still have the same dynamic behavior. Because what's going on is the way BGP works is a function of the diameter of the network, not its density.
So if the real question is, is BGP the most important problem we're facing today, is it really breaking down, do we have meltdown in inter-domain routing, is BGP scaling? The real answer is, you know, so far so good.
It's not the problem that folk have said. It's not that bad. But there's a really big caveat about that. Because there's no natural law that says the AS path length of the Internet, the diameter is exactly 3.8. It's you guys. It's the way you behave. It's your behavior in bulk that has actually made this happen.
So what have we done over the last 10 years that has actually kept this a constrained problem? The first thing that we've done is that we haven't deliberately gone insane with the way we hand out addresses. Over the last 10 years we have consistently said that addressing has strong alignment with the way in which the network is shaped, its topology. We use provider-based addressing deliberately because that's what makes routing work.
So our relatively tight adherence over the last 10 years to addressing policies that stress the importance of aligning addresses to topology, provider-based addressing, has been a fundamental pillar of the reason why BGP has been so well behaved. And the other part of that is actually the operational practices of you folk in operations. Because I know that I can't advertise any old Mac and get away with it. I have to, if you will, put a case into you guys, the folk who actually do the advertisement, for my route to actually get advertised or whether it just becomes part of your aggregate.
The continual stress of importance of aggregation in the operational community is what's kept BGP going. So as far as I can see, policies and practice have actually been the reason why BGP is so well behaved. It's not a natural rule that BGP has only this much instability and converges in that much time. It's an outcome of your collective behavior.
And the other part of this, which is equally important, is the fact that we have managed over the years to make the network no stringier than it is now. Its diameter is about the same. That's because of this phenomenal stress on local exchanges and local, regional, and global transit providers. Somehow we've managed to keep the density of the Internet growing and the diameter constant.
So as far as I can see, BGP is scaling. BGP is actually doing a remarkably good job, not because BGP intrinsically itself provides any natural limits to its growth. It could go haywire. It's because the way in which we've distributed addresses and the way in which we actually operate the network has kept BGP inside these relatively tight constraints. Thank you.
Tony Hain: So I would actually take issue with that very last statement you said and maybe make the case that it's not so much about how the allocations were done but there was an agreement about which ASs were announcing what. And the stability, the AS path length is the thing that causes the stability.
What prefixes they announce, be they PI, PA, geographic, really doesn't matter as long as everybody agrees on the set of prefixes that that AS is going to announce, and the stability comes from the fact that the AS path length is stable not the set of prefixes being announced.
That's what I would take from your talk and throw back and say I take issue with the one little piece about it needs to be PA, because I don't think that's actually true.
Geoff Huston: It's an interesting issue there, Tony. I must admit I always find it a little bit weird that although we have 33,000 autonomous systems out there on the routing system, only 4,000 actually act as transit. There are 29,000 stubs out there that sit one away from a middle core.
It's true that what seems to happen a lot of these provider-independent spaces, they grab an AS and hang one outside. Interestingly, that one outside doesn't breed folk further out. That has other folk do the same thing, and they still go one off from a core, one off from a core. So the core of the network remains tightly bound in size.
So is that provider-aggregate, provider-independent? Yeah, I could say it really doesn't make much of a matter.
Tony Hain: The source of the prefixes is really not the instability issue. And I think that is going to come back in a later discussion that Owen's going to have. So that's why I wanted to make that case here.
John Curran: Far right microphone.
Tom Zeller: Tom Zeller, Indiana University and ARIN AC. You said as we get to v4 runout you can't predict numbers. What do you predict the impact on the instability? From what you just said about the core and stubs, it seems like that by itself isn't really going to change that very much. But I do wonder about some of the policies that we're talking about that sort of make it easier for end-to-end enterprises to get their own numbering and if that's going to have an effect but not if it's still the core and one hop out to a stub. Wondered if you had any thoughts on future stability based on v4 runout.
Geoff Huston: The interaction between the fundamental topology and geometry of a network and addressing policies has to be recognized. I don't think the topology of a network is independent of the policy. They impact upon each other.
So when the current policy framework for v4 addresses disappears, because all that new demand -- and, quite frankly, last year we allocated more v4 addresses than any other time we've ever done it. So this industry is now rapacious in its demand for new addresses. And when we hit exhaustion, the bad news is we're going to hit it going at the fastest speed we've ever gone.
When the current policy framework breaks down and all of a sudden the way in which you get addresses is not by a policy framework of going to somewhere and asking for it but by a different mechanism, I, for one, have no idea what impact that will have on how addresses are used in a network topology.
I'd like to think, because most of us are optimists, and I certainly am, too, that the existing interconnection framework will remain unscathed. I'd like to think that. I have no reason why. I can't point to any law of networking that says topology is completely independent of addressing. It's not. So I look at three years out with concern, because I have no tools of saying, oh, yes, we did it this way in the past and that happened.
Nothing in our previous environment or history gives us any tools to understand what's going to happen in September 2012, except for one factor: That the pressure of growth and new connections is higher now than it ever has been. So the pressure to have something change at that point is going to be undeniably there. I just have no idea how it's going to express itself.
Tom Zeller: The singularity is near.
Geoff Huston: It is a singularity, I'm sorry, yes.
John Curran: Far right microphone.
Lee Howard: Lee Howard, ARIN Board of Trustees. I always love it when the routing table measurement and analysis working group convenes, so thank you very much for bringing back RTMA. Going back to an earlier section of your presentation, you were talking about the rise in the rate of growth of IPv6 prefixes and projecting it's going to be 25 years out before -- I wasn't clear on what number you were using for when it's equal to v6. Were you saying we'll have as many v6 prefixes as v4 prefixes by then?
Geoff Huston: I was using a metric of 80 percent. So when it gets to 80 percent of some future mythical v4 number, then you've sort of covered the same span of the network.
But the real point I was trying to make, Lee, was if we can get this done in two years, those numbers don't show it. In other words, whatever growth is going on in v6, if you want to get to a lot of the network in two years, 200,000-ish entries, that's a hell of a lot more than the 2,000 we have currently have.
Lee Howard: The reason I ask the question is that it seems to me that the way we allocate v6 is more closely aligned to one prefix per AS. I was wondering if, off the top of your head, you can project when that number comes close to convergence, prefixes and active ASs.
Geoff Huston: I did that, and it was 2017.
Lee Howard: Fabulous. We're almost there.
John Curran: We have someone at the head table, far end. Dave.
David Farmer: David Farmer, University of Minnesota, ARIN AC. You were talking about we can't predict some of the network topology things when the policy changes. Is there any -- there's other studies of network science, and they've used the Internet as an amazing thing to help define some new kinds of mathematics. Have we looked at if that can educate us on anything, when we hit this singularity?
Geoff Huston: I've never seen or heard of anyone working in this space. My mathematical skills are pretty limited. I just do differentials and least squares like everyone else. I've never seen a deeper analysis of this issue. No, I'm drawing a blank on that one.
David Farmer: Okay.
Jason Schiller: Jason Schiller, Verizon, UUNET, and NRO NC. Geoff, I think you're absolutely right in terms of the AS path depth of the Internet and the impact that that has on stability. But I think it would be interesting to look at another network that looks very different, the v6 Internet, which is a lot more sparse than it is in v4, if I believe the graphs that CAIDA are putting out. Have you looked at that at all? Have you looked at how that's changed over time as the v6 has gotten more dense?
Geoff Huston: I find -- I've got two vantage points in v6. One comes out of a right routing collector and one comes from APNIC's own. And the update rate coming out of RIPE is around 15 times the update rate coming out of APNIC. That shouldn't happen. I don't understand enough about the dynamics of the v6 network to even start understanding what I'm saying, let alone extrapolate forward.
It is a weird network. It's weird, I think, because of the incredible prevalence of tunnels. And I think tunnels alter the dynamic behavior of the routing system. So I'm not actually seeing apples and apples. I'm seeing a v4 network, which is underlying strapped to circuits, whatever, and they're phenomenally stable. And in v6 I'm seeing this hybrid of a number of effects that include structural tunnels which introduce instabilities that are having a hard time comprehending. And I find that very, very difficult. I don't know if anyone else has done work on the v6 routing table, but it's a really confusing place. It's small, but inconsistent. So I wish I could help at this point, but I'm still trying to understand the data myself.
Jason Schiller: Thank you.
John Curran: Center rear microphone.
Chris Morrow: Chris Morrow, ARIN AC and Google. So a couple observations about path length, the average path length and the reason it kind of stays the same. I think from a content provider's perspective, not an ARIN AC perspective, I think you see path lengths that are the same because there are restrictions -- people put restrictions on latency requirements. So I want to be able to get to you as quick as possible, so I try and connect to you so I can do that.
So there's a lot of things where I could go seven, eight AS hops away across an expensive transit, or I could just throw a cable over the cage, right, and connect to you here. So there are reasons why the path length stays relatively short, and they're mostly business reasons. So I would say that essentially money drives the meshiness of the network, sort of.
Geoff Huston: Where I live in Australia at the other end of an ocean, we didn't all band together and create one link creating a longer network. Oddly enough, like Europe, like many other places, we threw lots of parallel links across distances. So, oddly enough, we spent more money to make the network the same diameter, not less.
Chris Morrow: No, no, yeah, what I'm saying is you spent money in order to get better lower latency, higher bandwidth connectivity, right?
Geoff Huston: Yep.
Chris Morrow: Right. Same thing, sort of. So the other point is that, at least from when I was at UUNET, we noticed the number of multi-homed customers was increasing. So I think we saw in a couple of years like 30 percent increase. I don't have the exact numbers, and I apologize for that.
But it seemed like that was driven by compliance reasons or regulatory reasons, sort of which I think comes back to the network is more important to the business. So people are looking for better assurance that they'll always be connected to their business partners or what have you.
So I think that if you look at the end of days for v4, September 2012 or whatever, I don't think people are going to not want to interconnect more then. I mean, they're not going to want to interconnect any less than they do today. They'll have the same business reasons for wanting to do it.
So they'll try to find some way to get connectivity, either v6 connectivity, multi-homed or v4 multi-homed connectivity, so they'll buy addresses from their provider by buying an expensive T-1, right. Or whatever. I don't know what the final market will be, but there will be reasons why this will exist. I think the routing table growth really isn't going to stop then, right?
Geoff Huston: I still say it's a singularity, in the same way that I think trying to get a seat on a transatlantic flight today is a little bit of an adventure. Trying to get an IPv4 address in four years' time is going to be a little bit of an adventure. And then once you get the address, getting it routed is going to be similarly a little bit of an adventure as a consequence.
Chris Morrow: Hi, Verizon, I'd like to buy a T1 from you. I'm willing to pay $9,000 a month for it. Could I have a /24 of IP space for my 256 machines? Thank you.
John Curran: Okay.
Geoff Huston: I wouldn't have a clue.
Chris Morrow: I'm just saying, like, I don't know what the right -- I don't know what the end model is, whether it's two guys in a dark alley and they trade bits or whether it's me and Jason and --
Geoff Huston: Where I'm going to, though, is that --
Chris Morrow: You can't predict it.
Geoff Huston: The behavior of BGP is no accident, neither is it a fundamental law of routing that constrained it. It was actually this policy framework and this industry and its collective behavior. And when I look at other models of potential distribution, and the telephone system country by country just springs out into my mind as an alternative mechanism, and I think to myself would that mechanism produce the same outcomes of constraint and routing, my conclusion would have to be no.
Once you completely walk away from a policy framework that aligns addresses with topology and a framework that says topology and performance trumps national interest, which is where we are with the Internet, we don't have these artificial tariff barriers on every political border. When you get to that point, you get a routing system that's phenomenally scaleable.
The consequence is if you break that, and if you go to a country based numbering plan, I have no idea what the outcome is, but I'm pretty sure it's far worse than what we have today.
And that was kind of where I was heading in my own thought process.
Chris Morrow: All I was saying was there was a set of business reasons that drive the network the way it is today, and the AS path length sort of average, I see that as there's a business reason for that and the number of folks connecting at the edge to more than one provider, your edge, you know, single-homed -- sorry, multi-homed AS, that's a business reason, too. So I would capture those in your thing as well.
John Curran: I'm going to be closing the microphones, that includes the remote mics. If you want to participate, you need to move very quickly right now. Center front.
Jason Schiller: Jason Schiller, Verizon, UUNET. I wanted to respond to the one thing Chris said about I show up with addresses and will you route them. Yes, assuming I have slots left in my FIB.
Geoff Huston: Let me actually say, and I'll emphasize this with Jason, we've been here once before. And once before I was a victim in Australia. And that was when we passed the magic 20,000 number, and some bunch of routers somewhere over here in this country, over this continent with the NSF net hit the magic number and all of a sudden routes were being shared. And in the U.S. which routes got shared? Non-U.S. routes. So all of a sudden sort of everyone else was a victim and found themselves in a really balked topology that was only partially existent.
If we ever get to this stress point of FIB capability again and folk are having to make hard decisions, they will tend to maximize local money and minimizing expenditure, and, yes, some folk are going to get balked once more.
Jason Schiller: The point I'm trying to make: The concern is that I think v6 adoption, widespread adoption is going to happen in less than 25 years.
Geoff Huston: We would certainly hope so.
Jason Schiller: I think there's going to be a fairly quick ramp-up at some point which is going to result in a nearly doubling of the FIB entries, with v6 entries taking double if not slightly more space in the FIB than a v4 entry. So you're really looking at a tripling effect on top of the growth that we're seeing today. And that concerns me. And then throw on top of that a market for addresses that could lead to deaggregation. Throw on top of that the potential that you give every end site a /48, and now even small end sites have a bunch of bits that they can deaggregate to in order to do traffic engineering, whereas today a small end site gets a 24 and they can only have a single slot. All of this could lead to massive FIB growth.
Geoff Huston: But so far, Jason, I'm saying, yeah, right, and then all of a sudden I add to that what I heard about at APNIC a few months with this proposal sitting inside the ITU-T to go into country-based registries and saying instead of five let's have 200, each with their own policies and their own framework.
And I'm sort of going: Okay, at that point I'm scared, too, that the dynamic balance in this industry that has actually managed to keep routing at a level that its unit cost-efficiency has been constant all of a sudden goes out the door.
Jason Schiller: Well, and the important point here that I think you're making but you're not explicitly stating is when you have a country-by-country policy about how you deal with traffic, that necessarily means you cannot transit that country when going to a third country that has a different policy.
Geoff Huston: Welcome to the telephone world.
Jason Schiller: You're talking about actually constraining your physical network topology to mirror the country structure that's in place.
Geoff Huston: Topology and addressing policies are related.
Jason Schiller: That becomes very problematic.
Geoff Huston: We agree, topology and addressing policies are related.
Jason Schiller: I'm not disagreeing with you, but I'm not sure everyone in the room is catching your subtle point.
Geoff Huston: Neither do I, but thank you for emphasizing it.
John Curran: Okay. We have the mics closed. Do we have any remote participants? No questions from them. I'll ask one last one, Geoff. Since transfers inherently result in network addresses not following topology, and transfers -- like in the ARIN region we have a transfer policy that requires a demonstrated need we don't have multiple transfers. In the APNIC region there's a policy that allows transfers, but once we get to the point of depletion, if I remember correctly, the transfers aren't constrained in any way.
Geoff Huston: That's correct.
John Curran: You could have transfers that move multiple times further and further away from topology.
Geoff Huston: That is one of these tradeoffs that always happen. When you get down into when you start to lose your primary instrument of influence in an industry, these addressing policies have relevance, because folk are constantly coming to us and asking for addresses. Last year we gave out 200,000,000. So we must be doing something here. When we you lose that ability to influence the industry because you haven't got addresses to give away, and all you're then trying to do is constrain the actions of players by saying we will only bless your transfer with our registry entry according to the following criteria, there's a tradeoff between whether folk will still adhere to your criteria and live in your registry or whether they will simply go, you know, it's just a registry, we'll go and create our own over here and do what we want.
That tradeoff between still having relevance in a different world as a registry and saying that the real fundamental raise on debt for us after depletion, after exhaustion has done its job, is to be an accurate and the accurate record of uniqueness, means that my ability to influence the industry through policy is massively discounted.
So APNIC went the whole way. We want to be a registry. We will accommodate almost any industry action because we think being a registry is fundamentally important no matter what. But that was a value judgment in that community about why are we here.
John Curran: Got it. But there's no replacement mechanism to provide feedback to the routing system once APNIC's gone all the way with respect to just being a peer registry.
Geoff Huston: It's a singularity point after that. All hope is lost --
John Curran: I guess if you go all the way, it becomes a singularity. True enough.
Geoff Huston: Exactly.
John Curran: Thank you, Geoff.
Next speaker is Danny. He's going to talk about what they're seeing.
Danny McPherson: Danny McPherson with Arbor Networks. I'm going to talk about something -- a slightly different angle on this than what Geoff took. In general, he and I are in complete agreement. This is looking at some of the theoretical stuff and some data that was collected from a few different places and then go from there.
So, anyway, so the number of discrete prefixes DFZ size and what finds its way into the forwarding information base and so forth is one thing to look at. But if you're looking at routing system scalability, as Geoff pointed out, you have to also consider other things, like dynamics of interconnection, which we talked about, and how networks and topology can act together and so forth. And so I'm going to talk a little about that.
So a lot of times routing scalability, it's like, well, you know, people associate that with -- again, with DFZ size, how many routes are in a routing system. The reality is you could have 350,000 prefixes in a routing system but 10 million paths or 10 million unique routes.
In other words, I could have 30 ways inside of a core network to reach a particular prefix. So I'll talk about this in a moment.
And then a lot of the systemic effects of that, the topology, the interconnection, how things have evolved over the last couple of years and so forth, they have implications on everything from protocol design to implementation to how you might want to design your network to minimize those, to policy, again, as the previous talk was discussing.
So, anyway, this is sort of motherhood and apple pie to most of you guys. You kind of know this. But BGP is a de facto standard for routing on the Internet. You have a prefix or unique set of addresses, and then the attributes associated with that prefix.
And so one of the -- the distinction I'm making here is this prefix is one routing table slot. If it has a unique set of attributes, it's another slot. And lots of times you have many, many of those in the network. I don't think I need to discuss the rest of this and move pretty quickly through.
So, anyway, as we heard, again, and the last talk set this up nicely, is topology is sort of the boogeyman when you look at inter-domain routability on the Internet. Making connectivity richer and making it denser and trying to optimize connectivity should make things more stable in general.
And sometimes it does, but depending on where you sit in that topology, and it's very topologically sensitive, it can generate lots of additional turn, lots of additional instability that is localized in places because of dynamics of both iBGP and of eBGP.
Path hunting problem, which Geoff didn't go into this in much detail, but that's something that it if you're interested in the dynamics of why you see these different paths and how you iterate and the paths get longer and longer and so forth and how you search for those, and that's sort of the terminology to refer to that.
So what breaks first? Of course it's DFZ size. Everybody's like, yeah, the DFZ size. And that probably is the worst, because that's the FIB size. It's like how many entries does the TCAM hold. How much SRAM do I have on this, how do I deal with this line card issue, I only have half a million entries that can be supported by my hardware.
But on the route processor side, again, sometimes we see an order of magnitude more paths than the routing system. So I'll illustrate this for you in a minute. The thing is, if you have more routes, more available paths to reach any given prefix or any given destination, then you have more state, you have more churn, and that has effects from not only from the FIB size and FIB IO in particular but also effects on CPU and scalability and convergence and things like route flap dampening and so forth.
Again, it's highly topologically dependent. If you're sitting in Australia and you have one eBGP feed from a network and that's where you're collecting data, then that's one perspective. But if you're in the core of a network or looking at data from RIPE or route views or something like that, or inside of an iBGP topology inside of an ISP's network, the dynamics of the BGP are very, very different, depending on where you are in that topology.
If you own a network and you design network architectures and so forth, there are things you can do to minimize the number of unique routes or paths in the routing system, and there are things that you can't control as much, which is DFZ size, for example. This is actually pretty dated now. This is from level three, and the red line there is the DFZ unique prefixes. The green line, which you can barely see on the graph, you see is the number of paths or the number of unique routes they have for those same paths.
Level three is actually -- they've got about four levels of route reflection hierarchy in their network. So from a network architecture, routing topology or routing architecture perspective, it's a lot more complex than most people's networks, where you can add a layer of route reflection hierarchy in your network and cut the number of paths in half sometimes.
On the other hand, if you do that, then you might get more duplicate updates in your network or somebody might prefer one path over another because a cluster list link is longer and BGP decision algorithm considers that and so forth.
So, anyway, what I'm going to talk a lot about is actually the green line there and the growth and some of the effects of that.
So this diagram is sort of my stab at a conceptual router architecture, right? And what you see there is you sort of got a bunch of different functions feeding things into the IP routing table and router.
On the top right side -- I'm sorry; on the top left side you've got your BGP routing table, right? And that's made up of these things called adjacent RIB-ins, right, and you have an adjacent RIB-in for each one of your eBGP peers or iBGP peers.
And then you apply input policy and a decision algorithm, and then you get something called a loc-RIB, which is after the decision algorithm is made you say this is what I'm going to put as the best path in my BGP routing table, then you apply output policy and you advertise routes based on that policy. That's what you're looking at.
The loc-RIB is what most people think of when you think of DFZ size. So while on the left side there in some networks, you might have anywhere from 2 million to 10 million paths or the aggregate of the adjacent RIB-in. In the loc-RIB we're around 350,000, 330,000, depending on whose network you're looking at.
From there you have something. I termed it the routing table manager here. It's just something that R bits says I'm going to prefer connected routes over static routes over IS-IS, OSPF, over BGP. So something that's sort of R bits between the different protocols and provides preference. So then from there it says then this is the best route to reach a given prefix, so I'm going to install it in my IP routing information base. And then from there the IP routing information base is abstracted and you put layer two, you know, link information, like Mac address, other things, and you put in the forwarding information base, which is still stored on the route processor.
After you do that, then what you do is you take the forwarding information base and you populate that on each one of the line cards, for example, in the type -- in modern routers today where you have distributed forwarding information bases. So the interesting thing here is that anytime any best route changes, in other words, for a given prefix the best route may change without the prefix actually going away, just instability somewhere in the topology, then you see this and it -- basically the red arrow there -- there we go. The red arrow. So some change comes in from one of those BGP peers, it's like, oh, I prefer this path, so what do I have to do.
So what you have to do is you have to notify everybody else. You have to populate the forwarding information base. And then each one of those red arrows on the bottom right side of that graph is usually a serialized sort of three phase, like, hey, here's an update, thank you, here's an update, thank you.
I don't know how many people ten years ago had IPC issues on GSRs because that bandwidth was being exhausted because each one of those is serialized between each line card. And so it's a pretty complex process. And the more paths you have available, the more churn, the more FIB IO you have and so forth. So it has implications on the architecture of this.
Additionally, though, into these adjacent RIB-ins, and I'll show you a diagram of this in a moment, during the busiest times of instability, about 90 percent of the updates that you see from a given peer are exact duplicates. So then we make it into the adjacent RIB-in. So that's sort of a routing system effect that has implications on scaleability but it doesn't necessarily get reflected in what's in the routing information base or the BGP tables.
So why is the number of unique routes increasing faster than the number of unique prefixes? Again, this is topologically sensitive. So, depending on where you sit, you may not see this. It may be the same, exact same number. If you're away at some stub on the other side of the Internet, it may be the exact same number. But if you're in the core of an ISP network and you add new interconnections or you turn up new paths or peers outside of you or enterprises, multi-homed and so forth, then you'd see these numbers grow.
So lots of multi-homing, increased interconnection is, again, as Geoff pointed out in the previous talk, talked about, each new non-aggregated prefix brings multiple unique routes. I'll illustrate for you what I'm talking about. A lot of this stuff is largely the function of internal routing architecture. For example, you use route reflection, do you have a flat hierarchy, how do you interconnect with other networks, and then what do those other networks do. So, again, I can't say it enough, it's highly topologically dependent. Some people may have 350,000 total paths in the routers and some people may have 10 million.
When I was at Qwest in '99, we had 7 1/2 million, 8 million paths in the routers at that time. It was largely a function actually, as I'll illustrate for you, of the routing topology or routing architecture that we had in the network. So disintermediation is a term we use, basically sort of nixing the middleman. You see the content guys interconnecting directly with the networks and so forth. This is a common trend, right? The more dense the interconnection is on sort of the Internet routing topology, that path, the number of paths for any given prefix is actually -- actually grows, where the number of prefixes may remain more constant and more stable.
So I'll illustrate this. It's a pretty simple diagram, right, just looking at this. You've got an enterprise there, and they've got a /24 prefix and they connect to ISP 1 and they decide they want to multi-home, so they get another connection to ISP 1, and then they go ahead and get a connection to ISP 2 and ISP 3 because they want resiliency.
So, in essence, this is what it looks like. ISP 1 and ISP 2 and ISP 3 interconnect in two different places or three different places you see for each of these. So then what happens is they actually interconnect in ten cities, which is pretty common. So at the peering edge or the provider edge routers, the Ps in the network, or autonomous system board routers, whatever you want to call them, you've now got in this network 22 copies of that one route. But this is distributed through the network. So it's not so bad here.
So then when you take a look at it inside of ISP 1, what you actually get is this: Each of those -- each of those 22 routes ends up being 30 paths on each route reflector inside of a common network. So basically you learn the route from your client. You tell your route reflector, well, I need redundancy and route reflector, so I put two or three or five per pop, whatever the number is.
So each one of those route reflectors tell all the route reflectors. Well, they all prefer their local path, so they all advertise it internally, so each of these route reflectors in this network actually has 30 copies of that one single prefix because there are three networks with ten interconnection points.
So there are things you could do, like add a level of hierarchy and not see all ten clusters from each cluster and so forth. But it has a lot of implications. The multi-homing factors you see here, those are your routing topology.
So one other thing -- this was actually a PAM paper that was published recently, and it's just illustrating the fact that during the busiest times, the more paths you get -- the more interconnects you get, the more paths you're going to get to reach a given prefix. So even though the number of prefixes isn't growing as steeply, the number of paths associated with those and the amount of instability associated with a given prefix is growing very, very steeply.
So basically here's one AS. I think it's ACOnet. And the updates that we saw from them during the busiest .01 percent of the time, 97 percent of the updates you receive were exact duplicates.
Now, the interesting thing is because of stuff like route flap dampening, it doesn't keep those path attributes; it only does it per prefix. So each one of those duplicates would count as a penalty in a suppressed -- a suppress value in an implementation if you're employing route flap dampening. And so that's one of the reasons route flap dampening is pretty much useless use on the Internet today is because there's not path data associated with those unstable paths.
So I know I'm moving through these pretty quick, but we were behind, so I think we're doing all right now. When I say it affects everything, the ultimate sort of FIB table size isn't impacted, but the FIB IO is absolutely impacted. So that's something you have to think about, the capacity to update your forwarding tables on your routers. If you have more next hops and there's churn or instability, then it can have an impact on that.
The mechanics in multi-homing are really no different, right? Besides the fact that, as Jason pointed out, for example, v6 contains more FIB space and more bandwidth to update those line cards so forth, it does have an impact on the dynamics of the FIB IO and so forth, but v4 and v6, it's PA, PI, whatever. If you've got a unique prefix in the system, all this stuff applies.
Beyond the mechanics and the hardware size, the instability associated with this, there are lots of things implementations do, for example. Specs have been changed to optimize implementations that result in more systemic effects in the network. And so you -- but people don't look at a lot of that. They say, oh, the FIB size is fine, it's constant. But the CPU is churning away and the FIB IO and the back plane bandwidth and so forth.
So, anyway, what else do we want to say here? There are things on the protocol side you can do. Certainly the network architecture side, implementations can be more optimized. And I completely agree with Geoff's point about the policy having an impact on this. For example, in '95, whenever it was, Sprint decided to enforce prefix link policies and the fact that /24s are kind of the longest thing that can get routed on the Internet today and so forth. That's had huge implications.
And everything from here to -- if we look forward to routing security, for example, every path you have, you have to validate those, every new prefix you have, you have to validate those and so forth. So this stuff does have pretty far-reaching impact at the end of the day.
So, anyway, I think I went really quickly through these and probably got us close to back on track.
John Curran: Indeed. I want to make sure you get everything done and make sure that everyone has a chance to ask questions. So if you've got anything else you want to say not a problem. Got it all covered?
Danny McPherson: I think I've got it covered. I mostly agree in principle with pretty much everything Geoff covered. This is a different perspective. One of the key things here is there's some things here that both policy and network architecture and other things can have direct impacts on.
Something that also scares me personally, if I could, again, share a concern of Geoff's, is that today routing topology does not follow national borders, neither does aggregation or advertisements and so forth. And if you start to employ models that encourage that kind of behavior, then people are going to have to break up ASs.
For example, immediately when routing topology starts to follow national boundaries, deaggregation of prefixes and people that are multi-nationals, like take Google, for example, it's like, well, what address do you use? Where you're going to have to advertise these from that country, and it's going to be a censorship mechanism and so forth.
So I think that the impact of something like that on routing scalability is going to be really bad, and so we definitely need to think about that. Because I think the policy that's sort of inherent in practice on the Internet side is something that keeps it as stable as it is today. So, anyway, I think I'm just rambling now.
John Curran: Microphone open for questions. Remote participants as well. Any questions for Danny? Thank you, Danny.
Well, we were actually prepared to go either way and push the policy discussion that was scheduled after the break. But his -- Danny's great skill in bringing us back on schedule, I think we'll try to get this done. So next on the agenda is Draft Policy 2010-2, the /24 End User Minimum Assignment Unit. And I'd like to try to handle that now, and we'll be back on schedule. So let me do the introduction for this policy.
John Curran: Draft Policy 2010-2. Originally proposed, Proposal 99, on the 3rd of August 2009. Draft policy picked up by the AC in January, January 21st. And the current version is the March 2nd version. Shepherds are Owen DeLong and Dan Alexander.
Summary: Reduces the multi-homed end user IPv4 minimum assignment from /22 to /24. End users receiving less than a /22 from ARIN must renumber if they come back for additional address space. Very simple policy.
Status of the other RIRs: This policy is unique to ARIN. But you should know that there are existing minimums in the other RIRs that are somewhat relevant. AFRINIC has a /24 minimum. APNIC has no minimum. LACNIC has a /24 minimum, RIPE NCC has no minimum. So we're going from ARIN's minimum to potentially a minimum that's in other RIRs. Something to consider.
Staff assessment: Liability risk - no.
Issues or concerns: A little language issue. We have to make sure we understand the terminology of blocks versus prefixes and larger versus small. I think we got that clarified. But we will make sure it matches the rest of the NRPM obviously.
Resource impact: Minimal for the ARIN team.
PPML discussion: 31 posts by nine people. Six in favor, zero against. If I could get a /23 or 24, I would be in heaven. It's that simple. Lots of hoops to get through to get an ISP to advertise our competing ISP space.
At least in theory this proposal reduces the routing table load due to small multi-homed organizations. I'm not sure how that plays out, but it was one of the comments on the PPML. That's introduction to the policy. I'll now ask -- I guess Owen's going to come up. Owen, come on up.
Owen DeLong: Okay. So just a real quick review of the myth versus the reality around this proposal. There were some claims that this would increase the DFZ size. The reality is that nobody qualifies under this policy for space from ARIN that isn't already qualified for space from an ISP or possibly two ISPs, which in some case actually doubles the number of prefixes they're getting versus what they would get from ARIN. And that's how some people think it might reduce the DFZ size.
The myth is it will encourage address consumption. In actual fact, there a lot of end user organizations that are finding ways to justify a /22 just so they can get space from ARIN instead of getting the /24 they actually need. This will help spammers. No. The spammers actually want larger blocks than /24s. They're happy to get /22s justified no problem.
Today a single host which is connected to two ISPs can get a /24 from either or both of them and advertise it, them, through the other. This policy would allow someone with an immediate need for 64 -- 64 or more multi-homed hosts to get a /24 from ARIN. That's about all it really changes.
Haven't we discussed this before? Well, yes, we have, but we've had different objections to it each time. This version addresses each of the historic objections I could find in the PPML records and the meeting discussions. And it's still the right thing to do and there's still community need for it.
General objections: DFZ size. Anybody that qualifies under this policy can already put a route in the DFZ. So there's no real change there. And, in fact, consumption we've already addressed. Spammers we've already addressed.
Disaggregation: This version of the policy, unlike the previous iterations, requires people that get a /24 or a /23, if they grow, to return that in trade for a larger block. So we have no gain in the number of prefixes, discrete prefixes, presented in the routing table as a result of this. They'll have to renumber at least until they get to the /22 that they can currently get.
In summary, this policy is stricter than current PA policies. It will not increase and may actually reduce fragmentation and consumption. The PPML comments have been generally positive, and it's the right thing to do.
Marla Azinger: Marla Azinger, Frontier Communications. I don't support this policy. I'm not going to go into your myth and reality, but I don't agree with your reality. I'm just going to leave it at that. And then the --
Owen DeLong: Which part?
Marla Azinger: Pretty much all of it. Let me get my notes. I'm on Sudafed, so I'm having a little trouble today. So bear with me. My voice is really shaky because of it. And my train of thought is not going so well. So I should have grabbed my notes here. -- hold on.
John Curran: Microphones remain open. Far right side.
Dan Alexander: Dan Alexander, ARIN AC. One thing I'm curious for any thoughts from the room is my main hesitation is not so much what this may -- the purpose this may serve, but ARIN's ability to enforce this type of a policy, because I typically have an issue whenever a proposal suggests a requirement to return previous allocations or requirement to renumber.
Since this policy would be put in place right at the time when the v4 free pool is running out, I can see a fair amount of instances of this where someone would get their allocation, get the second one, which is now twice as big, and then surprisingly have network issues where they would never be able to renumber or return the first, and you've got a load of instances that ARIN would have to attempt to try and reconcile or go after right when their resources are going to be consumed by much larger issues with the v4 pool running out.
So in -- when I start thinking about us making sound policy, any proposal that requires renumbering or return of address space as a secondary condition of getting yet another block I typically have an issue with.
Owen DeLong: As it currently stands, they can get as many discrete /24s from their ISP as they want. So in the worst case where ARIN doesn't get the block back, I don't think we're significantly worse off than we are today with them getting multiple /24s from their ISP.
Dan Alexander: I'm not specifically referring to the blocks themselves. I'm referring to the liability and the resources required to reconcile them, whether it's the ISP or ARIN. ARIN is not geared up to go audit 15,000 blocks or even a thousand allocations.
Owen DeLong: I'd be surprised if this amounted to that much.
Dan Alexander: I think this will amount to a sizable -- there's a lot of people out there that would love to get their hands on a block of IP space. Because it's hit the major media outlets. Everyone knows this is coming to an end, so the land-rush is on.
John Curran: Thank you. Center rear microphone.
Marla Azinger: Fortunately Dan covered one of them. The spammers -- maybe from the point that you put it doesn't help them, but there's different points. So a spammer who qualifies for a /24 under this has no problem qualifying for the /24 using it, ruining it, transferring it, and then going and getting another identity, like they like to do, and then coming back and getting another one.
Owen DeLong: They're doing that with /22s already.
Marla Azinger: You're still going to increase the amount.
Owen DeLong: It's not worse.
Marla Azinger: Obviously we don't agree. Let's just leave it at that. Hold on. Sorry. Sorry. I'm really bad today. This would also put more of a strain -- your theory is it's not going to increase the number of people that are getting /24s. I don't agree with that. And it would increase the strain on backbone providers and what they have to do internally with their networks.
That's not visible to everybody I know, but to the operators that have to deal with that, it is. And the crap checker -- I administer IP addresses for Frontier, so I'm kind of a crap checker. So when people come to me and say, oh, I want to do multi-homing, give me a /24, I actually -- because we're kind of a niche group. There's not that many of us. We all talk. So I'll e-mail them or IM them and say, hey, did they get a /24 from you? Yeah, they did.
So end of story. They don't get a /24 from me. But as good as the ARIN staff is, that's going to increase the crap that they have to check and it's going to be a little bit more difficult for them than what it is right now with all of the rest of us helping them out with that. Okay. Sorry. Thank you for bearing with me. The Sudafed is kicking my bum.
John Curran: Comments? Okay. Far right.
Gary Giesen: Gary Giesen from Advanced Knowledge Networks. I'd like to come out and say I'm in support of this policy. The fact is it will actually marginally increase aggregation in the routing table because you've got a bunch of /24s peeled off of /22s or larger. And assuming customers can get their direct allocations from ARIN, presumably those /24s will be returned to the provider and they will be further aggregated and not reannounced as a /24 through some other customer.
Also, for some of the smaller ISPs where a /24 would represent a significant portion of their block, it makes -- and I've dealt with this personally -- it makes us somewhat reluctant to give them to our multi-homed customers, and then you end up with a fight over -- between us and their other provider -- who is going to give them the block.
It would significantly ease being able to bring multi-homed customers online, which is -- we want more redundancy and there's no extra cost in terms of routing table slots, but from an administrative standpoint for the ISPs, I think it makes it a lot easier. So I think it's win-win for everyone.
Kevin Loch: Kevin Loch, Carpathia Hosting. On the issue of spammers tarnishing the reputation of the IP blocks and then moving on to the next one, under the current system where they have -- presumably with /22s they'd have to go to an existing ISP and get the space from them and then multi-home that.
The ISP has the opportunity to defend the reputation of the block by kicking them off as soon as they discover that they're spamming or they get the abuse complaints, if they weren't smart enough to discover that before they took on that customer.
That also, of course, increases -- would increase the operational cost of the spammers ever so slightly. So I think in that case the current regime is beneficial on that argument versus them being able to continuously go out and trash /24s.
Owen DeLong: In my experience, working for an ISP that deals with a fair number of these abuse complaints, the spammers are having no problem getting /22s from ARIN and multi-homing their spam.
Kevin Loch: Right. But the block doesn't get significantly tarnished as long as they're not doing that -- as long as they're kicked off as soon as it becomes -- they become aware of the abuse.
Owen DeLong: You're talking about as a PA /24 that they're getting kicked off of rapidly. I'm saying they're going and tarnishing PI /22s no problem. This would allow them to tarnish /24s instead of /22s.
Kevin Loch: I did not see IPv6 mentioned in this policy.
Owen DeLong: This policy is strictly v4.
Aaron Hughes: I support this policy as written. The only concern that I can come up with is as we start to do some trimming as the time comes when we need to protect our FIBs, there won't be an aggregate block left back from any single ISP to get them back to. Whereas today if we're at least allocating from one side of one ISP having a larger aggregate, if we decide to trim /24s, at least it will still get back that announcement.
John Curran: Understood.
Owen DeLong: That's a risk that each user would have to evaluate. It would not preclude them from getting PA /24s.
Aaron Hughes: Sure. I mean, they may not be educated either, so it's certainly a good thing for our service providers to mention to the customers that are thinking about applying for the space.
John Curran: I'm going to be closing the mics shortly. Remote participants and on the floor get to a microphone. I'm also in line. People can't see my hand.
One quick question. This will change and make it possible for an organization to justify need for a /24, and historically ARIN hasn't had a possibility of that happening. Way over in another section of the NRPM, under transfers, it says that a block can be transferred to a designated recipient who qualifies for a documented need in the exact number.
So one interesting nit would be suddenly there might be a demand for /24 blocks that didn't exist before for designated transfers because a large number of entities might be able to qualify for /24, and suddenly every /24 Class C could be subject to a designated transfer. Where in the past you wouldn't have been able to do that because there was no recipient who could qualify, but now suddenly we're giving out blocks that match the swamp. Have you thought about that aspect of this?
Owen DeLong: Well, that would mean all those swamp blocks would get brought into RSA, and I don't see that being a bad thing. They're already advertised in the DFZ. So I don't see a negative consequence to that. I hadn't really thought it through. I personally think it would be a good thing.
John Curran: Just raising it so people see that. I don't know if it's positive or negative. I just want people to see that. Tony then Scott.
Tony Hain: Tony Hain, Cisco. I support this policy as written but probably for a different reason than people expect. While I do recognize that there is a FIB issue that our service providers are overly concerned about, I actually think this is potentially a good thing and a step towards the annihilation of the FIB that's going to happen once we're on eBay for address space. /24s are not what's going to be traded on eBay; it's going to be /28s and smaller. If you think the FIB is bad at /24, it's just going to get worse. You might as well ramp your way into that instead of slamming headlong.
John Curran: Interesting. Scott.
Scott Leibrand: Scott Leibrand, ARIN AC, Internap. I support this policy as written. I think it's high time that we go ahead and extend the boundary from /22 to /24. The routing table hasn't blown up. Every other RIR has got it at /24 or longer. I think it's about time. I think this does have some good protections that will keep that from happening if it were an issue.
To John's comment about the transfer policy, that's a major reason that I support this policy, because the transfer policy was written to follow existing policy, which means currently /24s cannot be transferred except to micro-allocation holders. That leaves a big chunk of the available space unusable. And if we don't pass this, we're going to have to think of some way to make those /24s usable.
And, in my opinion, the simplest way is just to go ahead and do it like this, make it possible to get /24s from the pool now, you can get /24s from the transfer market later.
John Curran: Lines are closing. Get to a line quickly. Center rear.
David Williamson: David Williamson, Tellme Networks and Microsoft. As the author of 2007-6 three years ago, which looked remarkably similar to this in most regards, it shouldn't be a surprise that I entirely support this policy as written. I think it's high time we move it to /24.
I don't think the downsides are going to be nearly as bad as some people think. I think the upsides including, like Scott mentioned, the ability to transfer legacy Class Cs without having to find a micro-allocation recipient all make good sense.
John Curran: Queues are closed. No additional people enter the queues. Center rear.
Wesley George: Wes George with Sprint. In general I support this. I think the one thing you didn't cover that's a potential downside to this is a lot of the traffic that came across originally in the list about why this was a good thing was renumbering sucks, we don't like having to renumber when we want to get out from underneath our current provider with PA space and that's why we need PI, which is sort of a legitimate concern.
But because of the way that this is worded now, which actually I support the change to say that they have to renumber to get into a /22 if they now qualify for two /24s, for example, it's actually a pretty good compromise. Because now renumbering sucks no matter what, but it preserves -- I think the best possibility of where it makes sense for people to do /24s that come directly from ARIN, great, if it still makes sense to do them through an ISP, that's fine, too. But that's the only thing that's sort of missing from the discussion.
John Curran: Far right microphone.
Dan Alexander: Dan Alexander, AC again. Just to clarify my point from earlier. I'm not necessarily opposed with lowering the boundary to /24. If everyone wants to do that, that's fine. My only hesitation is if we're going to do that, let's do it and -- because the renumbering requirement is where we're kidding ourselves. So if we're going to lower it to /24, let's just lower it to /24 and do away with the renumbering requirement.
Owen DeLong: The reason the renumbering requirement is in this proposal is because in the past the objection to the previous proposals was that it didn't have the renumbering requirement. So let's either -- you know, pass this and then work on a proposal to remove the renumbering requirement if we want to do that, or just decide that we as a community don't want /24s like the rest of the world has for whatever reason we have. But pushing the objection back and forth both ways to kill the policy both times doesn't make a lot of sense to me.
John Curran: Can I ask, Dan, I know you're not at the mic, but given that it may be difficult to renumber due to ARIN effort or lack of resources, if -- with the renumbering requirement in as it's written, are you opposed to the policy?
Dan Alexander: I would have to say yes. Because part of our role is to make sound enforceable policy, and I don't think this, as it's written, is a policy that ARIN can enforce long term.
John Curran: Okay. Thanks. Center rear mic.
Martin Hannigan: Martin Hannigan from Akamai Technologies. I don't know, I don't really have an opinion either way, Owen. I think sometimes we lack vision in what's going to occur, things that are coming down the line. And my initial thought here was that why wouldn't we actually push this, make these prefixes shorter and harder to get versus longer and easier to get?
And my thinking here is that as we approach exhaustion, and I'm not an advocate of trying to extend the IPv4 pool, and I can hear everybody else in the room talking, thank you, but I am an advocate of trying to figure out what companies are going to do that are going to need to kind of glue the Internet together in five years.
So, for example, Scott mentioned that perhaps /24s wouldn't be so useful. I can almost guarantee you I'll be able to use them for the next ten years whenever I can get them. Thank you.
John Curran: Okay.
Owen DeLong: So in response to that, Marty, I had a lot of discussions about this with some of the folks that actually do the registration stuff at ARIN. And, in fact, just this morning I was talking to somebody from Registration Services who basically pointed out that it's the /18 and shorter blocks that they're really going to run out of that they're going to have a pretty good supply of the longer prefixes for some time to come absent them having to issue large chunks of those combined together to try and make up some of these /9 requests or whatever.
John Curran: Yes, very much the case. Aggregate. Kind of like particle board.
Okay. Thank you, Owen.
Definitely going to need to get some guidance for the AC here. So I will fire up the tabulation engine. Yes, yes, remote. Yes. Okay. Good to know.
So we're going to take one show of hands on Draft Policy 2010-2, the /24 end user minimum assignment unit, those for and those opposed. When I ask you, hold it high until I tell you.
On the matter of Draft Policy 2010-2: /24 End User Minimum Assignment Unit, all those in favor raise your hand now. Nice and high. Nice and high. I promise you, if you're tired, there's a break coming up. Keep holding them. Okay. Okay. Thank you.
We're -- on the matter of Draft Policy 2010-2: /24 End User Minimum Assignment Unit, all those opposed raise your hand now. Nice and high. One hand per person. Thank you.
While we're tabulating that, let me say we're coming up on a refreshment break. We'll resume promptly on schedule at 3:20 with 2010-5: Reduce and Simplify IPv4 Initial Allocations.
Outside when you take your break, remember the help desks are there if you want to go talk to the registration services folks. We also have surveys that people need to complete. You can go online. There's information in your package about the survey.
And that's about it. So in about a minute, we'll come back here. Here it comes. Almost tabulated. Let me remind everyone about tonight's social. 6:00 p.m. We'll have a social tonight at the Academy of Spherical Arts. Should be a lot of fun.
John Curran: Okay. Here come our results. Okay. On the matter of Draft Policy 2010-2: /24 End User Minimum Assignment Unit, number of people in meeting room and remote, 135. In favor, 55; against, 12.
This will be provided to the AC for their consideration. Okay. We are at break. We'll see everyone back at 3:30. Thank you.
John Curran: If people would come back in, we'll start the session.
I'd like to welcome everyone back. If people will be seated, we'll get going. This afternoon we have one more policy to consider. It's Draft Policy 2010-5: Reduce and Simplify IPv4 Initial Allocations. I will do the introduction for this, and then we'll have the representatives for the AC come up.
John Curran: So original proposal for this: it was Proposal 102, submitted in the 5th of November '09. The AC picked it up as a draft policy on the 23rd of February. The AC shepherds are Heather Schiller and Rob Seastrom.
Summary: It reduces the IPv4 minimum allocation from /22 to /23. And ISPs receiving less than a /20 from ARIN must renumber if they come back to request for additional space.
The thing to remember: these are allocations. This is not an end user policy, this is an ISP policy. So remove the ISP minimum allocation down, and would have ISPs that receive less than a /20 subject to renumbering to maintain a smaller routing footprint.
Status at the other RIRs: there's no policy proposal, draft policy like this under consideration. But there is a minimum current policy in each of the RIRs. AFRINIC, APNIC and LACNIC have a /22 minimum, and RIPE has a /21.
Liability risk on the staff assessment: none.
Staff concerns: the fact that it states that there's a renumbering requirement means that ISPs will be held to that. ISPs who don't renumber will find themselves unable to obtain address space from ARIN. And it could be clearer without the word "initial" after its first use in the policy, can be fixed anytime.
Resource impact: yes. We need to do a little bit of implementation work to get the tracking of the renumbering requirement done, and we need to make sure we have a plan on what we do in terms of workflow for customers who fail to meet the renumbering requirements.
PPML discussion: the proposal when submitted was discussed on the mailing list before the AC picked it up as a draft policy. 38 posts by ten people, two clearly in favor, one against. The small single homers who are currently tied to LIR assignments that they are afraid will go away post IPv4 runout are extremely unhappy, would be overjoyed to get anything at all like this proposal.
I think the most important thing you can convey to your customers is that renumbering is inevitable. Two sides of the coin expressed.
That ends the introduction. I'll now ask R.S. to come up and do the AC review of the policy.
Rob Seastrom: Thank you, John. Okay. So John just introduced Draft Policy 2010-5. So, okay, this didn't get redone the way that I thought it was.
So the current requirements in the NRPM is you get a /20 minimum if you're non-multi-homed, a/22 minimum if you are multi-homed. And the information is actually sort of spread out over several sections and this policy proposal attempts to sort of condense that, rationalize it, and make it the same for both multi-homed and non-multi-homed sites.
So the crux of the change is the minimum allocation text. We're going to a /23 minimum allocation across all, across all types, and there's a requirement to return blocks when you renumber into a bigger block rather than simply getting new blocks assigned to you.
This means that it has both a -- that balances off somewhat the bad effect on routing table growth, because when you get a bigger chunk of space, you sort of have the -- it's the carrot and the stick. You have to renumber into the new space.
Here are the changes. Here's minimum allocation /23, lowers the requirements, harmonizes between multi-homed and non-multi-homed. Requires renumbering and changes the reallocation. But we still have to demonstrate efficient use of space, stuff to demonstrate efficient utilization beyond the new space, three-month window, and renumbering is necessary if you grow and let's see side effects.
It makes things simpler, but everyone is going to be under the same minimums. Threshold is lower. As I was saying earlier, routing table growth should have minimal impact because of return of the smaller blocks. Smaller allocation point means that people will be able to get to ARIN and get blocks that are currently not allocatable because they're too small, they're in fragmented space.
So it's a bit of a liability to be renumbering, so it's sort of pushes towards IPv6 as well. So there's some questions on the next slide that are clarifying questions I would like J.C. to ask for show of hands on. We'll entertain questions.
Mike Richardson: Hi. My name is Michael Richardson. I'm acting on behalf of a company called [unintelligible] today.
If I understand this right, I can get a 23 as a new ISP and can renumber three times before I get a 20 if I'm doubling in size each time. Is that correct? Did I understand that?
Rob Seastrom: That is my understanding.
Chris, are you out there somewhere?
Michael Richardson: Just wanted to be clear.
John Curran: Other questions? Microphones are open. Far right.
Kevin Blumberg: Kevin Blumberg from The Wire. Would this apply the renumbering of – to /20s, would that apply for existing ISPs who have 21s who are now going to get new space?
Rob Seastrom: That's a good question. I don't think that the proposal accounts to whether the effect on existing -- on existing allocations.
Kevin Blumberg: Because there's a major difference between, you know, an end user having to renumber. It's a very different thing when you're having to completely renumber your back end to get your next allocation and the customers at the same time.
I've already done this now three times in the last 10 years. Each time it gets exponentially harder to deal with. And so putting an onus on… at one hand you're giving smaller ISPs access to the system, but on the other hand you're making it for the ISPs that are legitimately using /21s, as an example -- you're making it far harder for them to actually grow their business. So I'm actually very opposed to the renumbering requirement as it stands right now.
Rob Seastrom: Would you be in favor of it if there was a grandfather clause for folks who had previously gotten addresses assigned?
Kevin Blumberg: I would be in favor of it, but at the same time it would sort of -- I would sort of wonder if you're now creating a two-class system for the very small ISPs who are going to get continually the crap knocked out of them every time they have to renumber -- three times to renumber before they get a /20.
So you're talking about three full renumberings of an ISP in a three-year period. They might as well just close shop at that point. You can't do that in the business environment today. So, no, the whole renumbering I've got a problem with.
John Curran: I'll let you go ahead.
Heather Schiller: For clarification to what he's asking. The policy proposal as written, if you have a 21 or 22 today, you are exempt from the renumbering for one year.
John Curran: Okay. Far left mic.
Chris Grundemann: Chris Grundemann. I wanted to also point out that part of the reason that Ted and I, the authors of this policy, thought it would possibly spur some IPv6 adoption is that not just the renumbering is onerous, and that really wasn't meant to be a stick to make people use v6.
The main thing was that if you qualify as a known ISP you can get v6 space. So these smaller ISPs that are maybe in rural areas where they don't have the option to multi-home could now qualify for their own allocation in v4 which would allow them to also get v6. It makes it easier for them to get v6.
John Curran: Just ask a question about that. And so there's an incidental benefit of making it easier for some smaller ISPs to get v6 and -- but that's incidental. That's not the main thrust.
Chris Grundemann: That's not the main thrust. The rationale behind writing this was those same small ISPs that are potentially in areas where they have one LAC they can buy from, they can't multi-home for whatever reason, they're small guys, what we don't want to have happen is for that situation to force them out of business.
When IPv4 free pool is exhausted, it's a very strong possibility that IP service with IP numbers, with IPv4 numbers will become much more expensive. And so if those small ISPs are able to get an allocation now, then they can continue to operate without having to worry about it.
John Curran: Got it. Far right microphone.
Joe Maimon: Joe Maimon, CHL. I support this proposal and understand people are concerned about renumbering, but you're probably better off if this is adopted than you would introduce something to strip the renumbering requirements, than to just oppose this proposal.
I do also want to point out on size requirements. Requiring people to justify needs for larger sizes has a side effect in that you're not rewarded for using your address space judiciously. You're penalized.
In other words, if you've signed up leased-lined customers, if you give them a /30 because they've got a single firewall, you'll pay for that, you'll have much less justification for your space. You might as well hand out 29s and 28s. That's something that I don't think is always addressed. People assume if you raise the bar you're improving things. There is a side effect.
Rob Seastrom: I would like to point out that that kind of thing is in fact why I don't have a /12 right now. Just it does allow -- that scrutiny is, in fact -- yeah, it's pushback, but it's pushback in the greater interest.
John Curran: Center rear microphones.
Marla Azinger: Marla Azinger, Frontier Communications. Do you have a policy statement you can bring up?
John Curran: Yes.
Marla Azinger: That way I can talk less. Okay. The second sentence of Modified 4.215.
John Curran: This one? Or are we missing a policy statement? Go to the full text.
Marla Azinger: My question is about where it's referencing blocks will be reserved for this purpose.
John Curran: On 4.225?
Marla Azinger: 4.215. Am I looking at the wrong thing?
Rob Seastrom: Forward or back? Right.
Marla Azinger: So it mentions doing -- reserving blocks.
John Curran: Right.
Marla Azinger: My question is what the intent there was. Are you actually trying to achieve classful routing or are you trying to achieve when we end up having smaller quantity subnets that they then deem them for this use instead of giving some that has a larger request to uncontiguous blocks.
Rob Seastrom: Chris can speak to that best. I think the intent was to accommodate length-based prefix filtering.
Heather Schiller: In ARIN today -- Heather Schiller, Verizon Business and ARIN AC co-shepherd. In ARIN today you will already reserve separate address streams for making ISP allocations under /20. They already do that today. So it's just retaining that part of the policy.
John Curran: Okay. Far right microphone.
Dan Alexander: Dan Alexander, ARIN AC. I share similar concerns with this one as the last one about the renumbering requirements. So I won't necessarily go into that one.
But one point I wanted to raise here is a year from now, year and a half from now, when we get into this depletion scenario with the renumbering requirements that are attached here, where if I have a 23 and I'm going to outgrow that and I want to move into the next block but I'm required to get a 22 and rather than a second 23, if all ARIN has left is a 23, does that negate any of these providers from actually getting that allocation because they're forced to stick with only one prefix.
John Curran: I see. The question is if the ISP cannot meet this requirement because we have no address space to let them renumber into.
Rob Seastrom: Transfer market.
John Curran: That's what the directed transfer policy was exactly designed to handle.
Dan Alexander: Agreed, but we also have like what's going to be discussed I believe tomorrow, like things like waiting lists and how to obtain smaller blocks to meet your requirements. This proposal would kind of close a lot of these -- the users who could take advantage of this are closed out of the ability to use those other proposals.
John Curran: Unless the policy text is specifically changed otherwise, correct. So I'll ask the question: As the policy is written, with that risk in mind, are you in favor or opposed?
Dan Alexander: Opposed.
John Curran: Opposed. Okay. Thank you. Center front.
Owen DeLong: Owen DeLong, ARIN AC and Hurricane Electric. I think Dan raises a pretty valid point. I don't think that the renumber and return requirements should be used as a way to not give somebody space that ARIN has just because ARIN has what they would need to grow into and not something that they can move into.
And I think that there's clearly policy work to be done in that area, and I'll start working on policy proposal.
John Curran: You might want to wait until the current batch settles so you know what you're deltering against. Microphones remain open. End-to-end, thank you.
David Farmer: David Farmer, University of Minnesota, ARIN AC. I just want to add, I don't know whether I'm for or opposed to this policy just yet. But there is a significant difference in the renumbering issue between this and the previous proposal.
The previous proposal was for end users. The scope of renumbering can be contained in a lot different way for an end user as opposed to a service provider. The service provider will end up requiring probably to end up requiring to renumber a number of end users. So the impact to the greater community is potentially much larger in this case than the previous case.
And an enterprise that wants to renumber, they can make that -- they can weigh that benefit whether it's a benefit to them to renumber and get the space or not. In this case there's impact to customers that may have little choice in the matter.
John Curran: So given that risk, are you in favor or opposed to the policy?
David Farmer: As I said, I'm struggling with it and I don't know either way just yet.
John Curran: Microphones remain open. I'll close the mics shortly. This includes remote participants who will hear this a minute later. So, okay, far right microphone.
Joe Maimon: Joe Maimon, CHL. I just wanted to point out that there are renumbering and returning requirements to get more space for this size of ISPs already. It's just that it's only PA space.
So in reality an organization is probably going to be hit with this kind of renumbering anyways. I don't see that renumbering in this policy should be a poison pill. You may not like it and you should probably move to rework it if it's adopted but it already exists, these kinds of renumbering.
John Curran: Okay. Center rear mic.
Glenn Wiltse: Glenn Wiltse, Merit. I'm opposed for the reasons that Dave Farmer just suggested. You know, to me, to have an ISP have to go ask their customers to renumber is just a little bit too much.
John Curran: I see some clarifying questions, and I'd like to make sure we have adequate discussion of these before we do a show of hands on any of them. So people have a view on whether multi-home versus non-multi-home ISPs should be distinct in the policies. At present they're distinct as a presence of threshold, correct? Right.
So does anyone feel as though a different threshold is appropriate or inappropriate and wants to speak to that matter? Find the microphones. Anyone want to speak to our current differentiation between multi-home versus not multi-home?
David Farmer: Speaking of the routing policy and creating routes if they're multi-homed in all likelihood, they're a route. So for a multi-homed it probably doesn't do much to change the status quo of the routing table. If they're not multi-homed that is not the case. They will probably create a new route. So I think there is a difference should we maintain that end policy, taking Geoff's guidance from earlier.
John Curran: Anyone think it's superfluous and isn't needed?
Rob Seastrom: Taking my hat off as a shepherd and speaking as an individual. Rob Seastrom, AC, Afilias. I've historically been in favor of flattening distinctions between allocations and assignments, that being end users and ISPs. And, likewise, I am in favor more in the interests of fundamental fairness than anything else.
Getting rid of any distinction between multi-homed and not multi-homed, that can't be defended on fairly serious technical grounds. While I'm concerned with routing table growth and got up to the mic to point out how many other times we've had routing table growth in the past besides when Geoff was speaking, I have a hard time believing in my own mind it reaches that point. So I'm in favor of this particular that there should not be a distinction between multi-homed and non-multi-homed ISPs.
John Curran: Okay. Other people like to comment on this? Either way: eliminating the distinction or maintaining it for multi-homed ISPs. Yes: name, affiliation.
Chris Morrow: Chris Morrow, Google and ARIN AC. I don't necessarily see that the distinction makes a lot of sense anymore. I don't know that it did in the past either. But it seems like now you could be multi-homed or not and plan to be multi-homed later, or you could have instances where you need the ability to do BGP regardless -- if you're an end site with a large block of IP space, you're probably creating some versions of routes in the network. So seems like there's very little -- that doesn't really hold any water as near I could tell. That part of the argument. So I would say get rid of the distinction.
John Curran: Okay. Center rear mic.
Cathy Aronson: Cathy Aronson, ARIN AC. It just occurred to me, because of something I've been working on with a client, that you could also be multi-homed but not in the current definition of multi-homing where you have a network that connects to a transit provider in the same transit provider in more than one location.
And you would want an AS number for that for a number of reasons. And so I think that the distinction is probably not as important as it used to be. And also if you're newly multi-homed or you're newly non-multi-homed and you go get an allocation, you're still making a new routing slot.
John Curran: Okay. Other people who want to discuss the distinction between multi-homed and non-multi-homed?
Okay. Another clarifying question is the allocation threshold. Okay. And this policy proposal lowers the allocation threshold, but presumably this is a question of should it be even lower, even smaller ISPs. So would anyone like to say that we should make it even lower? If so, find a microphone. Lower than a 23. Sorry, lower than 24, actually.
Rob Seastrom: No. No. Longer than the /20 and /22 that they currently are.
Marla Azinger: The questions were intended, if we didn't know what to do with the policy, to sort of spec out what parts we should continue to work on.
John Curran: Ah. If the policy was ambivalent about going forward? Not at all clear to the Chair. My apologies. Because I actually am somewhat uncomfortable with clarifying questions prior to a vote. But, yeah, okay.
And given that, that question isn't relevant unless the policy proposal doesn't go through. I saw a comment from the head table. Anyone else here? Yes, Paul.
Paul Vixie: Noting that ARIN is not a direct democracy, it's not really a vote. Show of hands.
John Curran: Right. This is entirely guidance for the elected AC to help make good policy. I'd like to defer, then, the discussion of the clarifying questions, and we can come back to them once we've had a show of hands on the main draft policy. So I'd like to thank R.S. Thank you, R.S.
Okay, time to provide some guidance to the AC. And the guidance is on policy -- Draft Policy 2010-5, Reduce and Simplify IPv4 Initial Allocations. We will fire up the tabulation engine. I see ready, ready and ready. Okay. We're going to ask for a show of hands in favor and a show of hands opposed on this draft policy.
If this policy is opposed, we may ask for additional questions to provide to the AC additional guidance, if it's apparent that there's not support for it in the room. But as intended, we're going to ask for one show of hands, all those in favor and all those opposed.
So on the matter of Draft Policy 2010-5, Reduce and Simplify IPv4 Initial Allocations, all in favor of the draft policy, raise your hand. Nice and high. Last exercise of the day. Okay, remote participants. Okay.
All those opposed to Draft Policy 2010-5, Reduce and Simplify IPv4 Initial Allocations, raise your hand. Opposed. All those opposed, raise your hand. Okay. Thank you. If we can bring up the clarifying questions.
R.S., you didn't project them from a laptop, so they should still be somewhere here. Okay. I was wondering if I was bringing up questions you had taken with you from the podium. No. So we have had some discussion of these clarifying questions.
I think that it might be useful, in order for the AC to mull over how to make the draft policy more acceptable to the community, whether or not there should be a distinction between multi-homed and non-multi-homed ISPs. So when the AC is working on this draft policy, the question is: Would the policy be more useful without a distinction from multi-homed/non-multi-homed ISPs. So that's what I'm going to ask. I'm going to ask the question. The question is: Would this draft policy be more acceptable without a distinction between multi-homed ISPs. Without a distinction. So a yea vote says I'd like a policy that doesn't distinguish between multi-home and non-multi-homed.
I'm sorry. Questions. I see Chris. Go ahead.
Chris Morrow: What if I don't like the policy regardless of the distinction?
John Curran: That we already expressed with a show of hands. The question is, if the AC keeps going forward with this policy, how would you like to see it come out. If you have a say in which is the worst of two evils, that's what you'd need to talk about.
On the matter of the show of hands that we just had, 2010-5, Reduce and Simplify IPv4 Initial Allocations, 128 people in the room and remote; seven in favor, 39 against. That will be provided to the AC. Since it does not appear as though there's a lot of support, we're now going to talk about how to make it more palatable.
So I am going to ask, based on the discussion we had, about whether or not the draft policy is more acceptable -- yes?
Scott Bradner: I'd like to echo that just recent comment from the floor. I think saying this is less distasteful if you go this way is not enough information. It would be better to say how many in favor of this change, how many opposed, how many would still not support the proposal or something that indicates that this change would not change the attitude towards the proposal.
John Curran: Understood. So given that the current draft has a distinction between multi-homed and non-multi-homed, what could be asked is: If that distinction were removed, would you be in favor of the policy?
So I'm going to ask one question first: On Policy 2010-5, if the distinction between multi-homed and non-multi-homed ISPs were removed, would you be in favor?
Yeah, go ahead.
Heather Schiller: 2010-5 removed the distinction. The intention with the questions was to ask separate from the policy, in general, should we remove the distinction. Should we lower the allocation threshold to consider each one of those things individually, so that if there was no consensus for moving this policy forward, we would know which individual items to work on.
John Curran: Independent of this policy? Okay. But since it's not tied to this policy at all, okay, is what you're saying --
Heather Schiller: Open mic would be fine or more appropriate.
John Curran: I remand the questions to the open mic. Feel free to raise them at that time. Okay. Thank you.
Mark Kosters: So one of the things -- I'm Mark Kosters, CTO of ARIN -- that we'd like to share with you is the number of the initiatives that we have underway in engineering that will affect you.
And the first two that we're going to be bringing up, there's going to be a total of four presentations that you're going to hear over the course of today and tomorrow that's going to be dealing with you in a big way in terms of how you're going to be dealing with us now, or, actually, more so in the future.
I'm going to be talking about two of them that are dealing with security-related sort of things. And I am keeping it deliberately high level so that you guys don't have the opportunity to take a nap.
So I do have a couple of pictures, too. And I'm trying to keep the acronyms to a minimum. Although, I've got two of them right here. So why are DNSSEC and RPKI important? Well, these are two sort of underlying lynchpins of how the Internet works today. Right? You have to have routing to send your packets across, and you have to know the IP address that's associated with the name, where you plan on going to.
And both of these things actually can be subverted by miscreants in nefarious ways and you won't know the difference. So we're trying to shore this up. And this is actually -- this is a pretty big initiative. Department of Homeland Security is putting some significant money behind this. This had sort of the purview of the White House. There's been a study done on both of these protocols in terms of what can be done to help secure them. Because right now, frankly, they're just not secure at all without DNSSEC and some sort of routing security protocol.
So what is DNSSEC? This is sort of the first one. This was the farthest along. You've been hearing about this for years. Okay. Sort of, I'm sorry, John, I have to have people raise their hand again, if that's okay.
So who has not heard about DNSSEC, raise your hand. Okay. We have one.
I'm really glad that Google's with the times. So DNS is not secure, right. We all know this. And there's been plenty of cases of spoofing attacks. I used to run the Internet years ago. And who remembers the sort of whole ownership over WHOIS information that occurred? And this guy named Eugene Kasparov got really upset, decided to cache portion everybody's nameservers, and guess who actually got put in jail for doing so?
So but one of the things he did, and we all knew this beforehand, is he exposed a weakness in DNS. And you can cache poison. Things have gotten better over time, but more recently there's been a number of, some research done that shows that even though there's been various Band Aids put on it, DNS itself is just not secure.
DNS, of course, attaches signatures to it so that you can, as an end-user or recursive resolver, actually validate those responses.
So what are we doing about it? So you're going to hear a presentation tomorrow from IANA about securing, about the migration of IN-ADDR.ARPA and also IP6.ARPA. IP6.ARPA is not really going to be migrated, but we're going to be talking about signing those two zones.
ARIN /8 zones under IPv4 have been signed since Q2 of 2009. And we plan on at some point allow you as end users or as ISPs actually to start provisioning DNSSEC for your zones that we've delegated to you through the reverse tree. And we estimate this will be available Q3 of this year, under ARIN Online. IPv6 delegations will be signed at a later time. Right now there's a slight problem with trust anchors.
I think Geoff Huston has talked about this. This is sort of big news. Helps melt the Internet, if you want to.
We're just not going to go do that unless we have to, and we prefer to keep our trust anchors to a minimum until our parents are signed. Therefore, we no longer need trust anchors. So RPKI, what is going on here? Routing today is insecure. Actually, I kind of like this statement that IAB put out: one of the things they put in it was routing by rumor. It's really true, really, when you think about it. You hear routes from others and you just accept them.
And they're really kind of rumors. Are they really true? Are they not? You really don't know. And there's various things that are really scary about this. And we've seen a couple of these sort of things exposed in sort of a more public nature. We had the Pakistan YouTube incident, right? That's sort of well known to everybody.
There's also a route server in China. Who really knows what's going on there -- there was definitely route leakage that occurred there.
And, really, there's no evidence of these things being malicious. But those people who intend to be malicious certainly could take this information and run with it.
So what does this do? What does RPKI do? Well, it attaches a certificate to the network resources. That's where we come into play, for autonomous system numbers and IP addresses. And it allows you as ISPs to associate the two from the Origin AS perspective.
And then you follow that chain to the top. Now, what I'm going to show in a few slides is how that actually works.
And so what can you do with this? Well, you can actually validate the origin. So you can feel more assured that at least the origin was secured. It doesn't say anything about the path between.
But at least that starts the whole concept of validated routing. And you need, essentially need to have minimal bootstrap information in terms of trust anchors.
Now, there's been a lot of focus on trust anchors. And IAB, as well as the various RIR COs, have put out a statement that we plan on going with the one single trust anchor at some point on dealing with IANA.
So this is coming to a theater near you. But it's going to be done in multiple stages.
So how does this work? Well, you are presented with a route. And then what you want to do is see whether or not this route is, actually the origin is actually correct. So you say, well, okay, I got this prefix. I stole this slide from Geoff, and he has actually a valid IP address here but a private AS above. I'm not sure why you did that, but it is what it is. So you go ahead and say: Here's the AS. It's associated with this particular prefix. Let's go ahead and see if the key actually signs it. Oh, Geoff.
Is that prefix correct? I think that's a valid prefix. It's through level three right now.
Geoff Huston: I got it wrong.
Mark Kosters: You got it wrong. Okay.
So does this private key actually match? Okay. Cool. It does. It is a certificate associated with that resource match. Cool. Now, can I go through the certificate chain to see whether or not these allocations have been given are correct as well? So you can reverse through the train to the IANA, which is your bootstrap, and says, yes, everything here is valid, therefore this particular route from a origin perspective is correct.
There's actually some pilot code that does some filter lists that actually takes leverages that Cisco's working on, that's been funded by DHS, evidently. That is coming to a theater near you.
But you can actually play with this today. We've had a pilot available for a while. And we would love for you guys to get some experience using this. It's easy to participate: really easy. Just ask for a user ID, give us a little bit of information and we'll go ahead and set up your resources so you can start playing with this.
Right now we don't have a lot of participation. It's been available for a while. So we'd certainly love to get some feedback, because we're going to go production here the end of 2010. And we like to try to get it right as much as we can beforehand.
And, again, feedback is really important for us, especially in the pilot phase as we're in right now.
There's two other parts that are associated with this. You're probably saying: Global consistency, what is that? Or in a single trust anchor. Right now everybody has their own trust anchor. So we have our own trust anchor. APNIC has their own trust anchor. RIPE has theirs. And at least two of the three of us are asserting that we have ownership over 0.0, 0/0, which isn't correct. So we have a lot of overclaiming via the various registries.
This is going to get better as time goes on. We're going to have sort of more global consistency, where we'll not only say, okay, here are the allocations given to various RIRs that will match between globally, but also the ERX portions that have been given but actually transferred from RIR to RIR as well.
So that all makes sense. Did I have a lot of acronyms that you guys say, okay, what the heck is this? Okay.
Open for questions.
Aaron Hughes: Aaron Hughes, 6connect. My only advice is we try to make implementation as easy as possible. As we've failed miserably at this with RIR, and we'll fail again if we don't make this really easy to implement with all of our vendors.
I don't know what that's going to take, but we as a community don't seem to create enough demand for it and it would be really nice to fix this. I certainly support the effort. But I would spend a lot of time making sure that its ease of use is a high priority.
Mark Kosters: So one thing I'll mention about the pilot is it's not as fully featured as some of the researchers actually would prefer it to be. But it is very user friendly.
So that was sort of the whole goal is to try to get this to have a nice flashy GUI and you go ahead and actually do the associations and other people or you can actually start validating these routes that you put in.
John Curran: Far right microphone.
Tom Zeller: Tom Zeller, Indiana University and ARIN AC. An earlier speaker was talking about the stability of the Internet vis-à-vis router processing as being second only to router slots. Geez, that looks like a lot more processing. What's the estimated impact?
Mark Kosters: So the initial -- this is all -- this is sort of moving from research into production in a way. Right now the work that's being done that's sort of demoed that I briefly alluded to is that all this sort of validation would be offloaded, and the validation would actually be done on a separate box and there would be a callout from your router to this box to get that validation stuff taken care of.
That's how it is at least initially being conceived right now. But it's a very valid concern. You're absolutely right.
John Curran: Far right microphone.
Joe Maimon: Joe Maimon, CHL. I did have a question. Regarding the Pakistani incident, how does securing the origination statement -- would that have prevented that? Could they not have injected that with their own copy of the route from a Quagga box? If it doesn't fix that, would it work for malicious instances?
Mark Kosters: I think Geoff wants to answer that.
Geoff Huston: Geoff Huston, APNIC. There's two parts to the current routing sort of design that's going on with securing routing. And one is that when you say this AS can originate this prefix, the object actually allows you to say the prefix using this length /24, /25, and no finer.
In the case of what happened to poor old YouTube, more specifics were actually launched in. Were they able to have said this prefix -- I think it was a /23 or a 22 -- and no more specific, it would have limited the ability of an attacker to only have attacked with the same length.
Now, when you attack with the same length, you're just having a war about AS path. So the first thing that would have done it would have eliminated the severity of what happened. You're about to ask the next question, which is, okay, so how about if I lie in origin.
Well, yes, you can conceivably sort of muck around with the path and keep the origin the same, yep. There's another piece of work that has to happen, which is about securing path. And that's a much longer piece of work. It's much more detailed. Currently, though, the certificate infrastructure that we're talking about here underpins both technologies.
So no matter how you sort of try and secure these instruments in routing, at some point you need to have these sort of pillars of trust to say where does that AS come from and who has legitimacy about manipulating it and advertising in the routing system.
And this certificate infrastructure is actually designed to inject that secure foundation.
Joe Maimon: Thanks, Geoff, but that leads me to the next point, which is currently it's an open community. It's consensus-based, as you've pointed out in some of the writings I've seen on your website, which thank you for those. It's pretty much we play this game because it benefits us all, but in theory you can all walk off to another registrar. Does this change the openness of the ecosystem at all?
John Curran: Could you clarify what you mean by you could walk off to another registrar? Just like --
Joe Maimon: Well, it's basically we're here because we like ARIN, and we are ARIN. But that could change if ARIN becomes ICANN.
John Curran: That would be a change, yes. Let me try to just make sure I understand. At present a lot of people believe the information in the WHOIS database that the RIRs run.
So the people in this room look at that as a source of information for where resources are. And because of that, while you don't have to necessarily use those numbers -- you can use other numbers; you don't need to use WHOIS -- you'd have to have a discussion with the other ISPs in the room about what they believe.
With RPKI, that information that we put in WHOIS we're also sending a certificate for, and if the ISPs in the room believe those certificates and enforce them, it's the same model. If they don't, the certificate's meaningless.
Joe Maimon: Is there a way for ISPs to change? Okay, this isn't covered in the certificate but I'm going to take it anyways? Or you're losing the ability --
John Curran: I can answer that. Directing the answer, ISPs can decide what information they're going to believe. And, in fact, I know there's some people out there that already are looking at systems so that they can take the certificate, the information in the certificate hierarchy and potentially replace some of that, if that's what's useful to their local policy.
Mark Kosters: And to add on to that, this is actually publicly available through the IETF.
John Curran: Far end of the table.
David Farmer: David Farmer, University of Minnesota, ARIN AC. I was going to say, all this does is certify the data that ARIN is providing you. If you want to get certification from some kind of other source -- I don't know why you would want to, but if you did, you could build the whole hierarchy yourself and use what trust anchors you believe. That's how certificates work.
John Curran: Okay. Center rear mic.
Danny McPherson: Danny McPherson, Arbor Networks. I was going to basically reinforce what David was saying. Today there's no authoritative source for who owns what address space on the internet, no cryptographically verifiable source. And this is building that infrastructure.
Absent that infrastructure, you can't secure the routing system. So you have to have this as a prerequisite for securing the routing system.
Now, obviously, if you employ this data to route on the Internet, you're sort of trading autonomy that you have today, that routing by rumor function, for security, right? And you'll have to give up something to get that. So that is an offshoot.
But to that point, right, trust and how you employ this is inherently from the bottom up. How you operate your network and who you choose to trust is going to be first, corporate policy and national security policy, and then you're going to go up the stack, right? So you'll have your local policies and then work your way up.
So I don't think this is changing anything. It's building an infrastructure. It allows people to begin to employ that for secure routing or for other things. You may use it for something besides secure routing. But today the fact that no authoritative database exists to verify -- cryptographically verify who owns what number of resources is -- it's kind of -- it's kind of shocking to think that's the case today.
So, anyway, I just -- I think I'm just reinforcing what you guys already said.
David Farmer: I want to slightly tweak that. David Farmer, University of Minnesota, ARIN AC. Sorry about that. To slightly tweak what you're saying, I think there are authoritative databases. You just can't verify the authority.
John Curran: Okay. Any other comments or questions? Be closing the mics. Okay. Thank you, Mark.
Andrew Newton: Good afternoon. I'm Andy Newton, and I'm here to talk about some new features that we're putting into ARIN Online. These are features that we are actively working on. So we wanted to kind of give you a preview of what it is you will be seeing shortly.
So if you go back about six months in your way-back machine, we've actually done a number of releases of ARIN Online. And going back about six months, we added in online reporting. So you could actually sign in and get reports e-mailed to you about your resources. We've also added in POC and ORG management where you can now do things in a much more streamlined fashion because you are linked to an ARIN Online identity. You could also do some recovery of your POCs and ORGs if you wanted to. And we've also done bug fixes.
Then on the back end, the public app that you see when you log in is really only half of the picture. We actually have a management app for the staff, which is the other half of the picture, and we've been making improvements to that as we go along.
So what is it that we are currently working on that you're going to see shortly?
Well, first off we have Bulk WHOIS access. Today it's done over FTP. It's going to be moving to ARIN Online. The next two items on here, API Key management and being able to track requests made over RESTful interface or through e-mail templates. In ARIN Online, the API Key management is what makes it possible.
As Mark talked about, to do DNSSEC you'll have to do nameserver management, give us your keys. You'll be able to that in ARIN Online soon. And as Leslie talked about this morning, POC validation. That will be coming soon as well.
Bulk WHOIS access: like I said, today that occurs over FTP. In the future we'll be doing this over ARIN Online. You'll be getting a RESTful URL so you can actually script this if you need to. Because we know a lot of people do scripting over FTP as well.
Just because it's in ARIN Online, you don't get around the Bulk WHOIS AUP. If you want this data, you still have to sign the Bulk WHOIS AUP. Once you do, there will be a download section. You can go to the downloads and get it.
API Key management. Basically API Key -- and we're going to have a presentation about this tomorrow which goes into further detail about API Keys and the RESTful interface, but API Key management allows you to take your RESTful request or your e-mail templates and link them to an ARIN Online user. That's its primary purpose.
And then once you're there, once you have something linked to an ARIN Online account, you can then have that linked to the POCs and ORGs and, therefore, the resources that you have with ARIN.
What this does, this kind of gives you -- for e-mail templates which you don't have today, it allows you to actually track your tickets in ARIN Online. Today when you send in an e-mail request, the status is really “you sent it”. Whereas, if you look at an X series ticket in ARIN Online, there are statuses like open, in progress, closed, things like that.
And here's kind of the proof-of-life that we've actually been working on it. This is a screenshot where you can go in and actually manage your API Keys.
As far as API Key generation goes, you'll be able to create as many as you need. There's no limit on that. We don't charge for it or anything like that. And you'll be able to deactivate them at will, in case one goes rogue on you or something like that.
There is a need for that. In addition, if you want to use e-mail templates, you'll be able to associate an API Key with an e-mail address, the “From” address from where you're sending the e-mail from. What that will do is that will go ahead and link those e-mails to your ARIN Online account.
That e-mail address does not have to be a POC e-mail address. It doesn't even have to be your ARIN Online e-mail address. If you have a system that's sending in templates that is disconnected or not related to your e-mail address or your POC's e-mail address, you can use that.
Managing nameservers: again, going into DNSSEC, we have to have a new model where you're allowed to hand us key information, and you're going to need to go in and provision all the information in a much more granular manner than you can today via templates.
So what that's going to do is basically we're going from network based to delegation based. So today when you say, oh, I have this network, you can give us the nameserver for each of the delegation points you have. We just take the set of nameservers and put them on the delegation points. Where in the future you'll be able to change the nameservers per delegation point and that will be in the ARIN Online, and here's a screenshot of that.
And then the last thing: Leslie talked about POC validation this morning. We're starting -- we'll shortly be sending out e-mails asking people to validate their POCs. We'll get an e-mail with a couple of links in there. We'll click on one link if the POC is valid. If not, they'll click on the other link and they'll come here and they'll see this message saying, by the way, your POC is not valid, please validate it. And here's the ARIN policy that this corresponds with.
That's really it. So --
John Curran: Questions on the new ARIN Online functionality? Okay. Thank you, Andy.
Adiel Akplogan: Thank you, John. So quickly, I'll give you an update on AFRINIC activities. At glance, we are 15 people working full time at AFRINIC today. From those 15, about 50 percent are new staff who joined in 2009. So it's quite a new team. And we are planning to hire more in 2010. If you're on our mailing list, you would have seen a few announcements for hiring already.
We are serving more than 600 members today, both end-user and LIR. We have just adopted our budget for 2010, which is around $2.1 million. And we are planning a significant growth in membership in 2010. I'll explain a little bit more about that later.
We have completed our 11th public policy meetings last November in Dakar, and we are preparing for the next one taking place in Kigali.
We have three policies currently under discussion in our region. Probably we'll see more before our meeting in Kigali as we have 30-day discussion period before the meeting.
As I just said, we adopted our budget for 2010. Key orientations of these budgets are the reinforcement of our technical infrastructure. We are revamping the whole technical infrastructure, moving part of them to Mauritius, splitting them also in different locations.
So this will take significant part of our budget. This year we are also involved in RPKI project as all the RIRs. So we are putting some resources there. We are also developing our own RPKI.
We'll continue to promote IPv6 in our region. We have seen, and there is no doubt that IPv6 is the solution for the future development of the Internet. And we have led this effort in the region and will continue to do that by dedicating our resources to that. So we are hiring soon a dedicated IPv6 program manager to support the different operators and especially government in understanding the issue related to IPv6.
As I said, we are going to hire eight or even more staff this year to reinforce the team to be able to tackle all the different challenges we face in the region.
We are also launching a new training plan which will be built around e-learning interface, related also on a few trainers that we're going to train. Not working for AFRINIC, but training point in different regions, different countries, people that we're going to train that can relay our training material to the local community.
We are also relocating our office in Mauritius to a new space. This is an ongoing project, and this expects to be finished end of May. That is about the budget.
But what we are doing currently, we are actually developing a whole communication plan to adjust our communication more to what we call nonconventional stakeholders, which are stakeholders that are not people we deal with usually, which are network operators, so governments, civil society, regulator, et cetera, because they are becoming more and more interested in what we're doing, but they always don't -- are not used to communication with. So we are reviewing this very thoroughly.
We have also decided in our budget this year to reactivate our associate membership category. This will allow us from survey and discussion we had to have those nonconventional stakeholders to formally be part of the committee by becoming members, even though they don't have resources from us.
In the technical area, as I said before, the RPKI is one of the things we are working on. We are also testing our routing registry, which is a future we are going to turn on in our WHOIS server soon.
We are moving from our current datacenter in South Africa to a new one, so that means taking a lot of planning to avoid interruption of service. We are moving to virtualization, and we are also reviewing our root server copy project. We have launched last year our root server copy project. We have deployed one fully. We are evaluating other.
But we have learned some lessons from that one we have deployed. And we are reviewing the whole program to make sure that it's sustainable and we got the right information to scale this to the level we want. So it is a project under review. And soon we will announce new deployment.
We also are working on DNSSEC deployment and reviewing our DNS provisioning system to include DNSSEC into it automatically. So that is a few projects on the way in the technical area.
I'll talk about 25 percent growth in 2010. This is because end of last year we have conducted an audit of our membership process to see what the process looks like and what is the feedback we have from members going through the whole process and how we can improve the membership process itself.
So the outcome of that audit, we are trying to implement that, which will allow us to complete the membership process faster and as a result increase the membership for next year.
We also are creating a dedicated frontline support liaison role to allow a more direct communication with new member or prospective member.
Policy discussion in the region. We have a new policy be introduced which is the abuse contact for incident response team in WHOIS objects.
We have an IPv4 soft landing policy, which is under discussion for the past 12 months or so, which is still under discussion. And there is a new policy to review our policy development process itself, to adjust it with the experience that we had in the region and make it a little bit more specific.
Some number. This shows globally how we are doing in terms of membership growth. You can see that we have constantly growing membership since we started in 2005.
As a result of IPv6 campaign, also we have seen important growth in IPv6 allocation in the region, not as much as we would expect, but there is a growth.
Within Africa region itself, we also see the distribution of IP address per country varies a lot. So we have today South Africa holding more than 50 percent of the IP address used in the region which is quite a lot, and we're still followed by Egypt, Algeria, Morocco, et cetera. So this is also impacting our awareness campaign and our communication and marketing in the region, trying to focus on countries where we have more potential but at the same time also refocus a little bit our service to the South African operators.
We also continue our cooperation with different organizations, locally and also globally. AFRINIC is a member of the NRO. We have continued to support the NRO through the different coordination group of other groups. And within the Executive Consul, too, we are improving our collaboration and involvement with regional organizations. We have launched our government working group earlier this year with a first workshop on cyber crime for law enforcement agencies.
We intend to formalize this group. There are even some very advanced reflection to make this group part of the structure itself. We had participated in several booths, more particularly, where we can meet regulators, government representatives, to reach out to them what we are doing and specifically on IPv6 in general.
We had a booth at the last African Union Summit, at, of course, the ICT Ministerial Summit, et cetera. And we've been appointed as an observer in the ICT Ministerial Conference of the region where we provide input to the different work they are doing in terms of ICT policy in general.
More to that, we also support other regional organizations like the African Association of Universities with which we're working very hard to actually try to get them involved, but at the same time participate more into training activity at the university.
Some announcement will come up soon in that regard. We also continue to support AfNOG, the African Network Operator Group, and AfTLD, which we are holding their secretariat for now. We have signed an MOU with the African Association of Universities, two MOU. The first MOU was to provide a 50 percent discount for academic network, when they are becoming AFRINIC member. And this last MOU allowed to waive the remaining 50 percent through special funding, so when you're an academic institution in our region, you become an AFRINIC member without paying any fee both for IPv4 or IPv6.
Upcoming events for AFRINIC: we have our meeting in Kigali, as I said before, early June. It's back to back with AfNOG meeting. So the meeting, the last two weeks, the last week is mainly for the meeting, AfNOG meeting, then followed by the AFRINIC meeting.
We are going to have AFRINIC XIII in South Africa, certainly in Johannesburg, finally. And AFRINIC XIV will take place the same period, end of May, early June but we haven't selected the venue yet.
That's it for now. And thank you for your attention.
John Curran: Thank you. Any questions for Adiel? Thank you.
Geoff Huston: Hello. It's me again. I'm acting Paul Wilson. You can spot the similarity. Same accent. He, though, speaks with more authority than me, so I just play a part. This is the APNIC update. And I'll try and be quick.
Very quickly, I'm going to talk about services, policy outcomes, some activities and some other news. We've been very busy handing out resources. Of note there, APNIC is now handing out about 40 percent of all IPv4 addresses on the planet at the moment. In 2008, we got through a little over five /8s. In 2009, we got a little over five /8s. And in 2010, over the first quarter, we've almost given out two /8s. Certainly that part of the world is seeing a phenomenal growth in both wired and wireless in v4.
Read into it what you will. But it's certainly extremely vibrant.
The other thing to notice is in v6, we've done 250 allocations this year. Last year we did a little under 200. So in the first quarter we've already handed out more than we did last year.
The one thing I find always very strange is that the world gives away, as I said, around 12.3 AS numbers every day. And wrapped in most of it -- and ARIN did a considerable amount. Down in the southern hemisphere we give away less than two a day. I don't know why we don't like AS numbers and you guys do. It must be a hemisphere thing. But we seem to be on record again that we'll hand out about 700 AS numbers. Around two a day. I have no idea why we don't hand out as many as everyone else, but that's the way it works.
We're a membership organization, of course, and not coincidentally with the run-out of v4, there's a lot of interest of getting address space from us and interest from members, and certainly in March 2010 we had 54 new accounts. So we've now got a little over 2,000 members, which isn't great. What it does mean, though, is still a lot of people use the phone to contact us and also other forms of online inquiries. We now do over 1400 a month, which is a growth of massive 55 percent over last year.
We've been running a certificate-based portal service, MyAPNIC, for some time. Feedback suggested that doing it purely on certificate-based access wasn't meeting folks' needs, and many members still like the whole idea of passwords. So we, in a revision of that project, actually allowed, as well as certificate-based enrollment, to actually do contact enrollment in that portal, reverting back to a password-based system if that's what folk want.
So now we support both certificate-based access and password-based access.
For a long time we've been what we call "debogonizing" /8s that we get from IANA. What that means is in conjunction, cooperation with RIPE, where RIPE actually very kindly advertised selected prefixes from our /8s, allowing folk to check reachability.
But as the bottom of the pool of v4 starts to get more and more imminent, the level of crap that we're getting in these addresses from IANA start to get more and more exciting.
In January, we were allocated 27 /8 and one /8, and one /8 was extremely exciting. RIPE started to debogon, to announce that, and they announced three prefixes including 188.8.131.52/24. They had 10 NET length, immediately saturated, went wireline, and that was it. So we thought this is fascinating. And we conducted some further experimentation with the kind cooperation of Merit and YouTube and Google and found that if you advertise one /8, you get 150 megabits of traffic day and night. Just love it.
A huge amount of that is actually UDP SIP port 15206, which is again fascinating. There's also a massive amount of scanning traffic and various attempts to bust in and out of stuff as well as stuff leaking from private networks.
We've done a huge amount of work on that, because obviously we'd like to allocate from that block. If it truly is toxic, we've got a problem. What we have found is actually that the amount of toxic traffic is concentrated in five /16s. So we're now feeling pretty confident that we can allocate all by those five /16s, and we'll continue to look at what's going on in those five /16s and hopefully release most of that space in the coming months as well once we understand a bit more about that.
Testing this requires a huge amount of transit bandwidth, something that APNIC doesn't normally have. So we're continuously on the hunt for folk with large amounts of bandwidth and machinery that they're willing to assist us with to continue to look at traffic coming into that. We've already started on the next two /8s.
Anyone ever use the Alice DSL service from Telecom Italia about three years ago? Because if you did, you would have been on Net 14; because that was the private internal network they used for that service at the time. They thought it was an X.25 PDN gateway network, it would never be used in the public Internet.
We've just started working on that one with the kind assistance this time of NTT. We get about 50 megabits of traffic into those two /8s. So once more, we're doing a very rapid piece of work to find out where the toxic hotspots are to try and make sure that no poor, unexpecting victim, i.e., person gets allocated those networks.
So that's been a new amount of exciting work for us. On the policy front, we've also not been slack. We've now done abuse contact information as a mandatory.
We used to have this very nice service about aggregation, that you'd hand us back your dispersed stuff that you accumulated over the years and we'd send you back a nice, shiny, bright new aggregate in v4. That's becoming harder and harder for us to service. And in response to that we've now stopped doing that in the latest policy initiative.
The other thing is Proposition 82. We've removed the initial aggregation criteria for those initial allocations. There was a strong move in our region in the policy community to make v6 as painless and as easy as possible to get. So that's certainly part of that work.
As we talked about earlier this afternoon, address transfers are now part of the framework and certainly transfer of registrations between current APNIC members and accountholders is now part of our policy framework.
And we've also done what we call a kickstart program. If you have v4 addresses and you want v6, you just simply click one button. It says: Give me. And the "give me" button will deliver you a prefix that matches in terms of policies what you currently have in v4 under the existing policy framework.
The really, really good news is that after about six years of intense effort, if anyone has been to an APNIC meeting in that period and saw us endlessly debating our fee structure, we have finally got a new fee structure. Yeah. With a 50 percent discount for the least developed countries. And there are a few in our region in that category.
We've eliminated that strange form of tiers, and now effectively the fee-based schedule is based on your holding pretty directly. Over M routing and research and development, we've been very, very busy, George and I and a few others.
As you've seen, we've been doing a fair deal of work in routing research, looking at the dynamics of BGP and the impacts of policies against what we see.
Also, if you've been to these meetings in the past, you would have heard me talk about RPKI. We have been working inside APNIC on this project since 2002, and very pleased to say last year we actually managed to get that fully into production.
So now inside the MyAPNIC portal, certification of your address holding is simply part of what we do these days. And we are certainly pleased to see the other RIRs attempting to play catch up. Who said rivalry was dead?
We've also been looking at DNS service dynamics. Like the other RIRs, we serve IN-ADDR.ARPA. And we are secondary for RIPE. And we were quite stunned in January with the amount of traffic coming out of one of our servers that was secondary RIPE, jumped from below ten megabits to over 30 instantly.
We thought this was an attack until we looked extremely hard at it and found this was actually a side effect of key rollover in DNSSEC. And the way the current system works, because the root isn't signed, folk load up trust anchors into their systems to say, yes, I trust IN-ADDR.ARPA because here's the keys. If you have an old key because you got it from some RPM release, and you're not following the key updates because RIPE deprecate the keys and roll them every six months, you will end up with old keys. So what? Aha. Old versions are bind prior to the latest work very, very hard when they find a key they can't validate against their trust anchors. They work extremely hard, and they don't ever remember that it doesn't work. So we had a relatively small set of resolvers causing 30 megabits of traffic.
This is an interesting lesson. And certainly we are awaiting as quickly as we can with baited breath a full hierarchy top to bottom to eliminate this kind of problem. It's certainly proved interesting, and we'd rather not go through another key rollover in the current state. So, yes, that's a salutary lesson. We're also starting to sign some more zones in DNSSEC because it's just so much fun.
I've talked about that test traffic measurement. Test Traffic Measurement Program. RIPE did this several years ago. We've actually expanded that into the Asia-Pacific.
One, it's a fantastic time source, true stratum, one. And, secondly, it produces some great data in how exactly the network is going. We've also been working The Day of the Life of the Internet Program, 3.4 terabits of data. And as I mentioned before, working in 10/8. So we're accumulating massive amounts of data. If anyone's got some spare disks, send them to me, I'll take them home and fill them.
Technically, working on DNSSEC. I've gone through that. And working on the RPKI. We're now going into a full Web service interface and doing reverse delegations with this as well and linking the DNSSEC signed zones to APNIC DNSSEC signed zones. So trying to use more of that certificate infrastructure to secure our communications.
We've being working hard on IPv6. We appointed me, which some of you would have seen in previous meetings full time working on IPv6 promotion. And certainly we've been doing well with that. We worked on the 10 percent media campaign when we got down to the last 20 /8s, sorry, the last 22, and we're now down to 20. We've done what we what call kickstart v6, which since February we've allocated 275 v6 allocations to existing members.
We're going to lots and lots of meetings around this area in the Philippines: APEC Tel in Taipei and Indonesia. If you were at the last APNIC meeting, you would have seen some considerable interest right now in the policies around IPv6 allocations and, in particular, some certain amount of, perhaps I would politely describe it as kite flying by the ITUT over alternate or complementary models of distribution. And we're certainly keen to participate in that particular consideration and also advance the view that the industry structure and the network itself benefits from the current setup.
In training and education, we've been doing a huge amount of work as usual. 77 courses in 36 locations with lots and lots of participants in 2009 with labs and so on. We're also doing online-based education, and we also collaborate with six deployed Team Cymru and intERLab.
Speaking of which, we did do a community consultation in Kuala Lumpur in the end of March over the perspective around the ITU discussion papers and their IPv6 group and put in a formal submission to that group relating from that community consultation.
We'll continue to participate in that and further programs related to that ITUT work this year. As part of that, there is the Pacific Island Telecommunications in the Solomon Islands, if you're cruising around that way. Or the World Telecom Development Conference, I think it is, in Hyderabad, in India, and the Regional IGF in Hong Kong.
We bought a building. There it is. We haven't put our branding on it yet, but we will soon. For some time where we are, we've found that it's actually possible at this point to accommodate our continuous growth in staff and the continuing escalations in rental costs to actually go and take some of our capital assets and buy a new building. So we are now in the process of refurbishing that to create a modern and well kitted out environment that all the folk in Brisbane -- I work in Cambra -- all the rest of APNIC staff will enjoy.
The next meeting: We're currently scheduled to go to Bangkok and Thailand at the end of August, and you are cordially welcome to come. And as usual, there will be remote participation by webcast, audio streaming and live transcripts. And that's the URL.
We are aware that there are a few folk hanging around out on the streets in Bangkok dressed in red. We're following that very closely. If there are some updates to that venue, we will certainly be posting them there in the coming weeks.
More than that, if it's feeling particularly cold and wet around this part of the year in February, you are welcome to come to Hong Kong where the weather is much, much more pleasant. We'll be having a joint meeting with APRICOT as usual, and also with the Asia Pacific Advanced Networking Group, APAN. And a year after that, in 2012, we're scheduled to go to Delhi in India.
John Curran: Questions for our speaker? Center rear.
Tony Hain: Tony Hain, Cisco. So while I appreciate that APNIC has taken on the task of scrubbing /8s that were allocated to them, a question, I guess somewhat to the ARIN community, is, should this become a community-wide effort to collectively run the set of tools and try to take what's left of the set and understand that before the allocations happen? A while back, Leo did some work on the suspicion that one would have some issues and was looking at the root zone and what was being flooded as queries from random addresses and realized that two was actually worse than one.
So given that two /8s has the potential to be worse than what you already found, one might want to go investigate that before it gets allocated.
Geoff Huston: The folk from RIPE aren't here, unfortunately. But I do know that they are working very hard on two /8. I will say that the work involved in one /8 wasn't technically a real challenge insofar as you simply run a massive packet capture for an extended period of time.
The interesting part of that work was that it was possible to isolate particular individual addresses, 184.108.40.206 and individual 24s that received massive amounts of traffic and the rest wasn't too bad.
Tony Hain: Understand. But it's finding those 24s, that's where the real work is. That's why I think if the community collectively said -- what's left in the pool? Because it's not that big a pool. And where are the hot spots?
John Curran: Let me step in. So we've already identified potentially polluted address blocks, and we actually have, as a group of RIRs, spoken and figured out that we don't want to have what is highly likely to be very clean address blocks all going to one RIR and what's highly likely polluted to be going to another. So we've paired them up, okay, for the final set.
And each RIR does scrubbing of the address blocks that they receive. ARIN does that. We actually -- at times we use Merit to help us out and others to announce and see the results of that.
So we haven't centralized it. But I do think every RIR is scrubbing the address blocks as they receive them.
Tony Hain: I suspected that was happening. But it's just more a matter of, given the amount of effort that Geoff's put into a toolset that has helped him here with the ones he's already been dealing with, is that something that should be generalized and made a more community-wide effort in advance of the last set of potentially polluted blocks going out? That was the question.
Geoff Huston: The only thing I did that is different is that in part of this exercise I answered the incoming sins, to tickle the TTP.
Tony Hain: To see how far it would actually try to go?
Geoff Huston: How far they would go. So it wasn't quite a fully passive measurement. The bit we did for incoming data was purely passive. And then as a second part of the experiment, we actually did try a little bit of active responding, just to understand whether this was pure one-way leakage, or if there truly was a two-way communication that was potentially possible.
Fascinating results. We'll be publishing the report soon.
John Curran: Microphones open. Center front.
Cathy Aronson: Hi. Cathy Aronson. I had a question about the "give me" button. I was at the APNIC meeting in Beijing. And there was some confusion about whether it was going to be automatically assigning one to everybody, v6 to everyone who had v4, or is it just a button that makes it happen really fast?
Geoff Huston: It's a button that makes it happen really, really fast.
Cathy Aronson: There was a whole big, long language barrier challenge discussion about it.
Geoff Huston: We presented this at the next APNIC meeting. Rather than doing it without you asking, you do indeed log into MyAPNIC and say, please, click, here it is.
Cathy Aronson: I was curious what it turned out to be. Thanks.
John Curran: Far right microphone.
John Springer: In February, APNIC adopted Policy No. 123, which is transfer, merger and acquisitions, take-over policy documents that states that during --
John Curran: Name and affiliation.
John Springer: John Springer, Inland Telephone Company, states that during the final eight, condition that APNIC will be allowing transfers to take place without needs-based considerations.
Could you comment on that, and perhaps give me an idea how that plays with some of your conclusions in your earlier talk today about how policy decisions have allowed for BGP stability?
Geoff Huston: Consideration of transfers took this community around about, the APNIC community, around about three years from the initial point where the initial idea was floated to the point where we actually decided to adopt a policy.
And certainly part of the debate, I think, was certainly the same debate inside this community, about the extent to which we were unleashing something that had no constraint whatsoever and to the extent to which needs-based allocations had some legitimacy.
What the community in the Asia-Pacific area understood is that while we were still able to distribute addresses within the current policy framework of needs-based demonstration, it made some sense to allow folk who wished to participate in transfer, the recipients to also demonstrate the same needs-based criteria.
That's the way the community felt. But the community also, I think, was willing to understand once that finished, once there were no more needs-based v4 addresses under the current policy available from APNIC, they felt that it didn't make much sense to impose that constraint upon transfers. Because at that point the community felt it was better to have a registry that reflected reality than a registry that only partially reflected where addresses might be.
So it was a case of, at the point where the control or the elements of influence you have from being able to distribute disappears, exhaustion, and then other forms of constraint don't make much sense either in terms of the registry function. That's the best explanation I can give. I hope it's reasonable.
John Curran: Okay. Any other questions for Geoff? Thank you, Geoff.
John Curran: Okay. Next up on the agenda is myself, actually, with an ITU update. I want to try to give a quick summary. Geoff touched on it, and actually Adiel touched on it a little bit. The RIRs have all been active in working with outreach efforts and education efforts to a new organization to the Internet numbering resource community.
The new organization is the ITU, the International Telephony Union. The essence of the situation is that while we have a very successful Internet registry system, seems to be working very well, the ITU has embarked on a process internally to review whether or not the registry system meets the needs, particularly the IPv6 number resource needs, for developing countries.
Folks may be aware that this actually was a resolution of the ITU to explore this matter, and it resulted in a study group meeting in Geneva. Prior to that study group meeting, we held a community consultation. Because of the time constraint, there was no opportunity to hold it here at ARIN. The RIR that was meeting at the time was APNIC.
So Paul Wilson and the APNIC team put together a community consultation session where we had speakers come and talk about the studies that had been done that led to consideration of an ITU IPv6 working group or study group, and we also let the community provide comments.
This was written up and provided as part of the input to the ITU. And in addition, the ITU invited select experts. Some of the RIRs are members of the ITU. They're what we call sector members. General members generally consist of countries. But sector members can be organizations that are interested in the happenings of the ITU. And at this time, for example, you have APNIC and AFRINIC are both sector members.
In addition to the sector members being able to participate, ARIN was invited as an invited technical expert in the field. So we all attended the first meeting of the ITU IPv6 study group in Geneva, and I guess the quick summary would be that the way the ITU runs a study group is probably somewhat different than how we run things here.
We tend to try to focus on the merits of the issue and don't worry quite as much about who is saying the sentences or what badge they're wearing. We tend to have documents that are published in advance. We try to make things approachable to people who are coming into the field. We don't always succeed. But it's a fairly reachable process. The ITU considered this an open process that they were running because they had invited select experts. But, in fact, if you weren't on the invitation, you actually were refused at the door. And the participation is a participation model that has worked for them. But it's a participation model that, while everyone has the ability to speak at some point, at the end of the day the ITU members are the ones that will get to decide what's in the written record of what was, quote, said at the meeting. And that written record actually defines what happens going forward. We're still -- it's been a few weeks. We're still in discussion of the written meeting report. There's some interesting discussion over what it should say regarding the official record of what occurred.
I'm not sure I can describe it any other way, other than to say it is interesting to be discussing what's supposed to be a record of a meeting and have debate over that. But we'll get there. The process that we're in is also a little unusual compared to how the RIR community does things.
There's a set of meetings that will occur between now and October when the ITU Plenipot will occur. The ITU Plenipot is a once-every-four-year meeting of all the ITU members where the ITU looks at its budget, its mission, its overall goals and objectives for the coming four-year period. In between, the ITU is run by a 45-member ITU council.
So this Plenipot is a fairly significant event to happen in October, where the ITU can actually pick up new work items and decide to proceed with them. As it turns out, IPv6 and Internet number resources could be featured at such a Plenipot meeting in October.
And the ITU has indicated that if its members say that it is to get involved in Internet number resourcing, resource management, then it will do so. As it turns out, it's quite possible that the ITU could do this without actually consulting with the Internet community or the RIR community. As a treaty organization, the ITU has some pretty significant items in its mission, and it can move into new areas working with the members, the countries. If that goes to a vote and is adopted, it will likely become binding on every region and every RIR because of laws passed to implement the findings.
So while it's not happening here, it has significant potential for actually impacting what we do. For this reason, the RIRs are spending a lot of time in education and outreach, trying to find out what is the problem we're really trying to solve, because we're not quite aware of developing countries that can't obtain resources. And trying to get to the heart of the matter, because obviously if there's a problem, we'd like to solve it with the existing mechanisms and the existing system, the existing RIR community to the extent possible.
Sometimes it's hard to see what the actual problem is. And to some extent we're not necessarily at the table when that's being discussed. Again, it is sometimes tables that only consist of ITU members or ITU members and sector members. So the short update is all the RIRs are participating in the meetings that we can go to. We are trying to make sure that the ITU understands the success that is the current system.
There is a hard proposal from the ITU that came into one of the recommendations, the C-29 recommendation, which calls for the drafting of a country Internet Registry Allocation model that would provide the ability for a country to obtain a country-based IPv6 block of addresses that it would then sub allocate. This is what Geoff alluded to in his presentation. We know how routing works to some extent with five RIRs. It could get very exciting with 180 of them, country-based. And so much of this is outreach and education.
ARIN actually finds itself in an interesting position, because while we are often invited, either invited as an invited expert or on the delegations of countries within our regions, both the U.S. government through the Department of State and NTIA Department of Commerce has been very helpful in working with us, Industry Canada, I know Heather's here somewhere, has also been very helpful. And also I will note that the outreach that those countries have done in these actual meetings have made it very clear, very strong support of the RIR system.
But we're not always at the table. And one of the things that ARIN is considering is looking into actually joining the ITU, as our sister RIRs have done, predominantly as liaison and education, so that we can be involved and make sure they understand what's out there. It's not something we look at lightly, because it is obviously an investment of money, an investment of time to have the personnel to participate.
But we're actually in a situation where we can't just turn and stick our head in the sand and hope for the best. This is an organization that can change the output of every policy we've ever done, without actually coming to the floor of this room. So something that we're actively looking at in terms of costs and staffing and how we would do that. But it may be something that's necessary for us to look into and proceed with, if it turns out it's cost-effective.
The other item, I guess, I'll point out with the ITU: I've said this before. I think everyone's heard it. To the extent that you are an organization that is large enough that you have people who participate in public policy, this would be people who participate at the ITU, or people who participate in other general associations, ACM, IEEE, ISOC, if you have people whose sole job it is to do public policy representation because of the size of the organization that you are, I'd like to speak to those people. I'd love to hear their names. I'd like to give them an idea what we're doing. To some extent, it's very important that we coordinate on these matters so that the ITU is hearing a unified set of voices from the people currently participating in the registry system.
I know some of the folks, some of the carriers out there and larger companies. I do have the current contacts. If you have someone in your organization that you think does public policy, bring them to my attention or Cathy Handley, so we can let them know what we're saying so they can understand that and won't be surprised. Likewise, if they want to lend their efforts to it, that would also be helpful.
That's it for the ITU update. I will take questions on this, though. I probably have as many questions as you do.
Milton Mueller: Milton Mueller, Syracuse University. I just want to comment, and maybe Cathy will correct me, because we've been discussing this, but I think you may have overstated the degree of the threat that you're stating. When you say something like the ITU can undo everything that happens here without ever coming on the floor, I think that's very much an overstatement.
And what happened in mid-March, as you're well aware, was that we had an extremely tedious meeting in which there was about 50 people adamantly supporting the RIR system, which includes almost all of the key governments who are major players. And we had Syria. And it turned into a dialogue between 50 countries, all the RIRs, all the Internet technical people, all the vendors, and Syria. And not a single country, not a single country came out unambiguously in favor of what Syria was saying there.
Now, there may be countries that have surreptitious support for that, but I don't think there's a big risk of the ITU as an institution imposing its will on the Internet community in the manner that you've discussed.
The threat is that individual nation states who believe that nation states should control the addressing system, with or without the ITU, can do things. And some of them already have done things. So I think Korea has tried to do things. And China, we all know what China is doing to make the Internet a nationally bordered net.
So I would focus more on that issue and not get too exorcised about the ITU. Definitely, you should participate in these, what are they calling them, correspondence groups that are being formed. I think in any free and fair discussion of these issues, again, it's a lopsided debate here. The level of technical expertise, the level of knowledge, the level of commitment to making the Internet work that exists here is simply no match or is the match by far for what's on the other side. So make your troops a little more optimistic about what's going on here.
John Curran: I appreciate that. In fact, I truly hope that your vision is true, because hearing that there's a less significant threat would be a wonderful thing. I guess I will distinguish, to the extent that countries want to get involved and establish policies for the use of Internet or Internet resources in their country, that's obviously a sovereign matter, and that will happen, and many organizations here have to deal with the outcome of that as they see fit even today.
The reason I distinguish that matter from the matter of the ITU is that it's important that people understand that the ITU is capable of passing recommendations and resolutions in manners that don't necessarily reflect a clear discourse and a clear understanding of why. In fact, the resolution that led to the study group which we're presently at, the C-29 resolution, you would be hard-pressed to find the record of where the merits of exploring that matter were adequately communicated beforehand and rationally discussed in a manner that this community would understand.
So while I do think hopefully you're right, we are part of a nondeterministic process, because to some extent the procedural matters can actually thwart any discussion of the merits of the issue under certain circumstances. And that's why we need to be present.
Front microphone. Owen.
Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. I was fortunate enough to be at the APNIC meeting in Kuala Lumpur where this was discussed. And I would like to applaud the community that was present and the ITU representative, actually, who was there. I think she was very fair-minded, very open to what we had to say, and I think that the discussion went very, very well.
And I think we did a great job of communicating our position to the ITU at that discussion. And it sounds like we got a very good outcome from the meeting. I look forward to the minutes if they ever get published.
John Curran: We hope to.
Far right microphone, Raul.
Raúl Echeberría: Thank you. Raúl Echeberría from LACNIC. I think Milton's comment is very interesting. I tend to agree with him. I have the impression today that this intent from some people related with ITU will not be successful. That is the impression that I have today.
And I am very optimistic in that sense also, like Milton. But it doesn't mean that we don't have to take care of this issue, because I have the same impression about the meeting. Nobody's supported in the meeting, serious proposal. But after the meeting, I had opportunity to have a chat with ITU Secretary General, and after that and after seeing an interview that was published with the one senior staff member of ITU very close from the Secretary General, I have the impression that there are people still in ITU that still have the idea to push this project forward.
So it doesn't make sense, in my perspective, after seeing the reaction from many governments to those ideas. And I would like also to comment, in the meeting that was held in Geneva, the representation of the governments was not very high.
And the number of governments presented in the meeting was not very high. It can be interpreted in different ways. But some of us were, the week before, I think, of that meeting in the Secretary General Assembly. InterAmerican Telecommunications Commission. And interesting resolutions were approved there, and very supportive of the RIR system.
So I think that probably the number of governments that were not present there, in fact, only one from Latin America was in the room and were not the highest level of representation. I think it could be interpreted like many governments are not really interested in that. But so it doesn't make sense in my perspective. As you said in the beginning, it is a very strange process for us, because it's very different.
In the RIR community, this idea, I would not perceive with -- I think it's probably the advisory committee of ARIN would say, okay, if there are just one in favor and 100 against, that it doesn't make sense to go ahead with the idea. But ITU was different. So I think that's why we have these ambiguous signers from ITU, I think we have to continue working on that and being involved with the discussion. Thank you. Sorry for the long interpretation.
John Curran: Thank you, Raul. No, very good. Adiel.
Adiel Akplogan: Just to give some perspective and maybe emphasize what Raul just said. I think the impression is that Syria is leading this. But the threat is two-way.
We have Syria and some government who do not express themselves very vocally like American representatives will do, Canadian representative will do, or European Union will do. They hid themselves behind the speaker, which would be Syria. So it will be silent support or nonsupport or no view at all on this topic.
And the way ITU works, and then when it comes to take a decision, the vote will pass, without any strong -- so the environment is very tricky and different from what we know. By talking with the government in our region, for instance, they clearly say we have no idea. We have no point of view.
We believe in ITU because we have been working with ITU for the past year. So we tend to believe what ITU is saying. But we don't have a clear position now. You are giving us your position as AFRINIC. We understand you are doing a good job. But we are a government. We have to look into this as intergovernmental issue. So it is tricky. And I think the most important thing is for us to be there when the decisions are being taken, when discussion is being done as we did in Geneva, so that is very critical.
Second thing I guess is that the threat is also internal to the ITU. There is ITU staff, ITU involved people who are interested in what is happening in the technical community and want to be the privileged interpreter for many governments in this area, so they will want to do that. Not that they want to do my job, but to have this privilege and relation with government when it comes to Internet operations. So that is something. And in general we have to adapt ourselves also in the way to communicate with this stakeholder because they are different, and we have to adjust if we want to get attention.
John Curran: Thank you, Adiel.
Okay. Any other questions regarding the ITU update? If someone had told me 10 years ago I would be giving an ITU update here, I would have been surprised. Here I am. Okay. Thank you very much.
John Curran: We are now on to the Open Microphone session. So this is available for any questions you might have on ARIN or policies. Policy, draft policies that are on the agenda are not for this section. They already have a slot. That's when they should be discussed. But anything else is available now for the open mic.
Paul, would you like to chair this? We generally have the Chairman of ARIN handle this.
Paul Vixie: Anyone? So we're running a little bit over time here so it's okay with me that everybody would like to go visit their rooms before getting on the bus to the social.
Closing the microphones. Anyone?
Joe Maimon: Joe Maimon, CHL. Earlier this year, the Board made some changes to the Board and to voting members, in response, I believe, to things we brought up in the past just as not just friendly changes to the control and direction of ARIN.
But there wasn't much talk about it. Was that expected? Or is that what happens? Is my read any different? Do you think we possibly might be going in a direction, overshooting the mark perhaps?
Paul Vixie: Can you hum a few bars? Could you give me an example of which change we made to the Board or to the election procedure that you're particularly wondering if it could have been overshot?
Joe Maimon: Well, the membership eligibility restricted now only to resource holders. It does significantly rule out -- it used to be you could say, well, anybody can actually really, really participate in everything, you just need to pony up a few dollars. That's changed.
The Board has also kind of widened the gap. You can't have everybody rush in in one year; vote immediately afterwards, and also the Board of Trustees added a new potential seat voting member.
Paul Vixie: So I can explain a little bit of sort of what was going on that led up to that, which was we had an anti-takeover committee. We were a little bit concerned that our reserve might look attractive to some outsider who could say, gee, let's flood the ARIN membership with a whole bunch of new members and then replace the Board and then write a big check to ourselves or something along those lines.
So what we were trying to do is make something like that either take just an absurdly long period of time that it would be undesirable, it wouldn't pay for itself, or to make it outright impossible.
I'm not surprised that there wasn't a lot of discussion about it. That was the other part of your discussion, or other part of your question. This is corporate governance wonkatude stuff that a lot of people don't take much interest in.
Is there a concern, either real or imagined concern that you have about something bad that might now be possible that wouldn't have been possible before that perhaps we're moving the organization in the wrong direction?
Joe Maimon: No. My personal opinion, this was quite right, I actually had talked about anti-takeover needs beforehand. And I was sort of expecting this. But I just wanted to point out that there is always a possibility of moving too far just as, for example, ICANN. You could be something like that, which I personally wouldn't want to see.
Paul Vixie: I don't think I want to use this podium to compare and contrast our governance to ICANN's governance. What I will say is I personally am comfortable that we have not overshot the mark. I understand that it's a different sort of deal to have members be resource holders and to have it not be something that you just pay a fee to become.
We could not find a lighter weight solution to the problem. If you have a lighter weight solution that you'd like to propose, either now or later, we're listening. We can keep moving this. We can keep fine tuning it. But all I can say is we sat around for a long time trying to figure out what could be done. And this was our best series of ideas.
John Curran: Paul, if I could add one more. I do agree with that. I also want to not underestimate the risks we might be facing compared to another organization. Over the next five years, there will be a period in time when it occurs to someone that, with the right circumstances, a policy proposal could effectively seed the remaining IPv4 address space to their organization.
If you were to successfully capture the AC and the Board, you could make a policy proposal that organizations located in the state of whatever whose name begins with the letter Z are entitled to the remainder of the address space. And if you got it all the way through, you could find yourself in a very interesting situation. The pressures we're going to see as we get to depletion are going to be unique, unusual and one-time, and that might mean tighter controls than you'd otherwise adopt.
Joe Maimon: Also, regarding ARIN's nature, we're an open community. But are there any numbers to back up that assertion? Do we know who's represented well and who isn't? Who shows up? Is it only the big corporations? What segments? Percentages? Who is here?
Paul Vixie: Yes, there are just numbers. I think we'll be presenting something like that on day three.
John Curran: We can present a breakdown of the membership stats. But in terms of participation, I'll note that we have, for example, presently more than 50 remote participants that participate at no cost. So I don't know how we could have a meeting with participants who have no cost and no overhead who get to speak and participate in the show of hands. I'm not sure of a more open participation model that's out there for us to emulate.
Paul Vixie: Thank you, John. I want to note the microphones are closed. If you're not in line now doing so would be pointless. I would also like to say we're structurally transparent and structurally open.
For example, policies are not decided by members. In fact, the board has several people on it who are not employed by ARIN members. The PPML is open to non-members. This meeting, where policies are debated, is open to non-members. So to the extent that we are making policy that affects the whole Internet economy in our region, we're doing it using the whole Internet economy in our region, not just the people who qualify for membership or who choose to become members.
Martin Hannigan: Hello, Mr. Chairman. Martin Hannigan, Akamai Technologies. I think you've done the right thing with the anti-takeover measures. And I'm looking forward to an update or some discussion at some point -- not necessarily now -- on the question that I asked at the last ARIN meeting, related to the NOMCOM and the ASO, I'm sorry, the AC elections.
And I think that along with tightening down the hatches, we ought to be careful so that we can continue to move in and move out the people that we want to represent our community, not with so much ease that we can hijack the organization, but that it's still possible for us to be displeased and show it through elections. Thank you.
Paul Vixie: Thank you, Marty. Those of us who are up for election later this year are keenly aware that we can be ousted easily. And that was actually a litmus test for the anti-takeover measures.
Lee Howard: Lee Howard, ARIN Board of Trustees. I wanted to respond a little further to Joe's question about whether, I guess, large ISPs are disproportionately represented here.
If you go to the ARIN website and look at the Toronto meeting, there is a link to attendees. And you can see who is here. And you can do your own analysis.
I did review that before coming here, because I like to remind myself of people's names. And I generally just sort of impressionistically, it looks to me like there are very few large ISPs represented here and a great number of small ISPs.
That's also consistent with what I've seen on PPML. And that when you do a show of hands, either on the mailing list or virtual room, or in the physical room, it's number of hands that are counted. And every once in a while I post some of my greatest hits from PPML. I did an analysis some years ago of number of postings by people from different sized organizations. And those were, the vast majority were from small ISPs.
I will confess I work for Time Warner Cable, which could be considered a large ISP. But if you look at the membership of the Board and of the Advisory Council, you will find -- you will not find a predominance of large ISP representation on either organization.
Paul Vixie: Thank you, Lee. The concern I have about that summation is that it sounds a little bit self-serving or self-congratulatory.
So my challenge to Joe or to anyone else, either here in this room or out there remotely participating, is that if you think there's a problem with openness, transparency, governance and so forth, raise it. Raise your concern. Either come here, use the mailing list, talk to the State of Virginia, and complain about us as much as you feel you need to in order to solve the problems that you perceive.
If there are problems, I, myself, would like to see them identified and solved. And I think you'll find that is universal among the Board.
John, did you want the last word?
John Curran: I just want to say, we'll give some stats on the breakdown of the ARIN membership. But the extra large and large categories historically have been numerically 100, 125 total compared to a membership of 3500 organizations. So when it comes down to who gets to vote on the AC and the Board, I'm not really -- if anything, I'm waiting for the guy who stands up and says I'm X percent of the Internet traffic, I'm X percent of the address space, why do I only have one vote.
The current flat organization voting model is truly as open as you're going to get and might actually be accused of being not a representation of the people who run a lot of the Internet but we run it anyway, and they've tolerated it all these years.
Paul Vixie: Thank you, John. That concludes sort of the open mic hour for today. Let's do it again tomorrow.
John Curran: Thank you, everyone.
[Meeting adjourned at 5:41 p.m.]