Table of Contents
- Opening and Announcements
- AC On-Docket Proposals Report
- Regional PDP Report
- Internet Number Resource Status Report
- RIR Update - APNIC
- Today's Mobile Internet
- RIR Update - LACNIC
- Draft Policy ARIN-2011-7: Compliance Requirement
- IPv6 IAB/IETF Activities Report
- IPv6 Panel: Successes and Setbacks
- Draft Policy ARIN-2011-1: ARIN Inter-RIR Transfers
- IPv4 Countdown Plan
- Open Microphone
- Closing Announcements and Adjournment
John Curran: Good morning. If everyone would be seated, we'll get started now. Welcome to Vancouver. I'm John Curran, President and CEO of ARIN. Happy to see all of you here bright‑eyed. I also know we have quite a few remote participants. Happy to see them. I have a couple of announcements and introductory remarks. First, the Board of Trustees is at the ARIN meeting as usual. Paul Andersen, our Treasurer, Scott Bradner, myself, President and CEO. Vint Cerf is not here. Hopefully he's watching remotely in between sessions in Geneva. The Internet Society has its Global INET meeting in Geneva this week and Vint can't be in two places at once. So he's actually over there. Tim Denton, our Chairman. I know Tim's here somewhere. Yes, thank you, Tim. Sorry. Bright lights. Paul Vixie is here. Yes. And Bill Woodcock is here as well.
So we also have members of the Advisory Council, if you would raise your hands. AC. The Advisory Council is the body elected by you to advise the Board of Trustees on policy matters, including their able Chair, John Sweeting, who will be giving a report shortly. We have Chris Grundemann participating remotely, out there in the ether somewhere.
The NRO Number Council, the constituents from this region elected to participate in the Address Supporting Organization advisory group which advises ICANN on global policy. Ron da Silva. And Louie Lee, the Chair. Thank you. And Jason Schiller. See these people, if you have any questions about global policy, they're the ones to ask.
Our RIR colleagues are present from AFRINIC. Fiona and Alan. I know you're out there somewhere. From RIPE NCC, Axel, Andrew, Andrea, and Hans Petter. Yes. Yes. Yes. Yes. From APNIC, Adam, Geoff Huston, Wita, German. Paul and Naresh, quite a contingent from our friends from the Asian Pacific region. And from LACNIC, Sofía, yes, in the back. Very nice.The RIRs attend each other's meetings because we want to keep aware of what's going on, keep you informed of what's happening in other regions.
Our management team, of course, is here. Myself. Our Operating Officer, Nate Davis. Nate? Yes. Somewhere. Nate's probably operating somewhere. Cathy Handley, our Executive Director of Government Affairs, is not here. I'll be giving her report. Bob Stratton, our CFO, the man you deal with on the bills and the money. Susan Hamlin, who runs the meeting, her group. And many of you met, if you're a first‑timer, you met her in the First‑Timers Breakfast this morning. Our CTO, Mark Kosters, and Mary K. Lee, who handles HR and administration, and Leslie Nobile, who runs the registration services desk that you all deal with.
Okay. Fellowship Program. ARIN has a Fellowship Program where we sponsor folks to be able to come and participate in ARIN and take those lessons back to their regions. The fellowship recipients at this meeting from Canada, Lynne Hamilton. Lynne, are you out there? Welcome. Glad to have you. From the United States, Frank Hoonhout from the state of Oregon. Frank? Yes, very nice. And I'll say Kadian Davis, Kadian, are you here? Yes, very good. From the University College of the Caribbean.
By having the Fellowship Program, it lets us help get the message out to people who otherwise wouldn't be here, they can take it back to their communities. It's a worthwhile initiative. They all have mentors assigned from our Advisory Council to help them learn how policy is developed, answer any questions they might have. I'd like to welcome all the First Timers. You folks were at the breakfast this morning getting an orientation to ARIN and the policy process. ARIN's open to anyone, and happy to have you here at the meeting.
We actually have a drawing now, so I will invite Mr. Owen DeLong, come on up, if you would draw one piece of paper from this basket of all the first‑time attendees evaluation forms, we'll give out a $100 gift certificate. Sean Wang, you'll receive an electronic gift certificate. Thank you.
John Curran: Thank you, Owen. Okay. Remote participants. We know you're out there. We have webcast of the proceedings. There's a live transcript being performed. I ask people speak clearly and not too quickly for sake of the transcription folks. There are downloadable meeting materials for all the presentations.
There's an online chat room where there's a virtual mic. You can approach the virtual mic and ask a question. We'll arrange for someone to read it. We have people monitoring up here. And during a show of hands, if we do a poll regarding policy support, you can participate as a remote participant in the show of hands. It's important to remember for those times that you're not at an ARIN meeting and we're meeting somewhere you can still participate remotely and have the full ability just as if you were in the room.
Okay. Participants’ packet. You all have a packet of information. It has the meeting program, what we're doing. It has the Policy Discussion Guide and the Policy Development Process. The Policy Discussion Guide covers all of the policies that are going to be considered over the next two and a half days. It contains a copy of the current Network Resource Policy Manual, which is the manual that ARIN staff uses in the management and administration of Number Resources. The policy proposals are what's going to change that Number Resource Policy Manual. It has information on our social event. We're not all work; we do have socials. We have a wonderful one set up tonight. It has the ARIN Standards of Behavior. We conduct the meeting according to standards of behavior to maintain decorum. We ask everyone pay attention to the standards of behavior. Those have been adopted by the Board. They basically talk about how to have respect and treat everyone with dignity.
Interacting with ARIN. A little guidance on how to interact with us, if you have questions or requests. The Open Suggestion Review, in addition to policies, the community's welcome to suggest, make suggestions on how we operate ARIN, areas like policies, fees, services. And we actually bring those now ‑‑ as a result of a past suggestion, we now bring all open suggestions to this meeting. And so there's an open suggestion review handout in your participant's packet.
And then understanding the IPv4 Transfer Market and ARIN Transfer Options. We've had enough questions that we decided to put a little handout together. This information is very similar to what's on the website that explains transfer policy, transfer options, our listing service, which is optional if you want to participate, and that shall help put everyone on the same page on this information.
Attendance stats. Question marks everywhere. We're going to get to attendance stats. I'll report it at one of the breaks. I'd like to thank our sponsor. Network connectivity is provided by Telus. Thank you. Instrumental in making sure we have a successful meeting as a high‑bandwidth connection, particularly one that has v4 and v6. Rules and reminders. Our chair, Chairman Denton, will moderate the discussions of draft policies so all can speak and be heard. Please state your name and affiliation each time you're recognized at the microphone. Please comply with the rules and courtesies that are in your program.
Today's agenda. We have the Advisory Council reporting on its On‑Docket Proposals Report. We have the Regional Policy Development Report. We have Internet Number Status Report, the status of all the numbers in the inventory. Two of the RIRs, APNIC and LACNIC, will be giving reports today. We have an update from the liaison to the IETF on IPv6 activities. We have an interesting presentation by Geoff Huston on today's mobile Internet, which is illuminating in terms of the challenges we face with managing Number Resources. And we'll have an IPv6 successes and setbacks panel.
We also have a couple of policy discussions. We have Draft Policy 2011‑1: ARIN Inter‑RIR Transfers. This is a policy recommended to the Board. The Board asked we have a final consultation at this meeting, which I'll be conducting. We also have ARIN 2011‑7: Compliance Requirement. Normal AC presentation on the status of that policy, Draft Policy, and discussions as to what's happening next with it.
Tonight's social. We have tonight's social at Grouse Mountain. So this is important. It's at a mountain. It's up at the top of the mountain. You have to ride up there. It is important that people understand they need to get on the buses and ride to get on the shuttle to go up to the top. So buses begin loading at 5:35 PM Okay? There will be one 38‑passenger bus going each time to the mountain. Bring your name badge, and if you're going on the snowshoe tour wear boots. You can find information in your packets. One of the things up on the top of the hill in addition to entertainment and a lot of fun, some lumberjacks, is, for those who want, a snowshoe tour of the top of the mountain.
That would be boots, not high heels. Return buses begin coming back at 8:00. You don't need to spend the night. You can jump on the bus and come right back if you want. Reminder, attendees who registered using ARIN's group code received the in‑room Internet is complementary. So if you're in the hotel, you registered through ARIN, that's going to be complementary. If you upgrade, then you pay for the upgrade. And please check your bill. Okay? If you're only getting the standard Internet connection you should not have it on your bill. If it's on your bill, note it at check‑in and have them remove it.
To start off the day, at the head table up here we have Tim Denton, we have Cathy Aronson, Bill Woodcock, Bill Darte, Paul Andersen, and Kevin. Thank you. I always do that. I always blank out on someone. Kevin is on the AC. I'd like to get started right away. The first presentation is the AC On‑Dockets Proposals Report by John Sweeting.
John Sweeting: Good morning. I'm John Sweeting, Chair of the Advisory Council. And I'm going to run through a very quick presentation on the proposals that are currently on the AC's docket. Proposals that are currently on the AC's docket. There are none. All the proposals have been converted to Draft Policy and are going to be presented here at this meeting.
On Wednesday… it's very important that we hear your opinions here at this meeting on all the draft policies that will be presented, because on Wednesday afternoon the AC will review each one of those draft policies and what transpired during this meeting as well as on the PPML and will make decisions.
I think that's pretty much all I need to say about our meeting on Wednesday. We have a couple of AC lunch table topics that will be today and tomorrow. There's two: 8.3 Specified Transfer improvements will be at one table, and improved communications for policy development will be a separate table. They will be probably very crowded tables, so try to get there early if you want to participate in one of these discussions. That's it. Thank you very much.
John Curran: Any questions for John on the report?
John Sweeting: Excellent. Thank you, Bill.
John Curran: Thank you, John.
Einar Bohlin: Thank you, John. My name is Einar Bohlin. I'm the Policy Analyst at ARIN. Part of my job involves going to other RIR meetings, reading their lists, and seeing what's going on in those regions. So at each meeting for the last couple of years I've gone about this time and taken a survey of what's being discussed and proposed at all of the RIRs together. And I've been tracking that over time. To explain this slide, the first column there or set of columns is the topic of IPv4 address space. And the green and purple is last year, 2011, and we really saw a spike in IPv4 policy discussions and proposals last year throughout all of the RIRs. It's definitely tapered off. The blue, the far right blue line is this time frame. v6 remains a constant; a steady stream of proposals. Small, but making light changes to v6 policy around the regions.
Directory services continues to be a topic that's being discussed. And there are a couple of other categories there. But as you can see, the total number of discussions going on right now in second quarter 2012, is 29, approximately 29 discussions on all of the different topics at the RIRs. So we have six draft policies on the agenda this week. Three of them are really unique to the ARIN region. There isn't really anything like these things at the other RIRs. And three of them have some similarities. The ARIN Inter‑RIR Policy, 2011‑1, has adopted policy in the APNIC region, and there have been discussions in the LACNIC region, and just last week RIPE had a meeting and there were discussions about inter‑RIR transfers there. I'm sure we will hear more about what happened there from Axel when he gives the RIPE update.
We have clarifying requirements for v4 transfers, which is also the same topic really as inter‑RIR transfers. So it's got the same discussions in those regions. And we're looking at changing our v6 allocation policy for subsequent allocations a little bit. And I put down discussion at the RIPE region, not because they have the same exact thing here but they're looking at changing their initial policy because folks ‑‑ some folks have said that the ISPs in that region didn't give enough initially. So they're kind of looking at additional space from a different angle.
So these are just some ‑‑ I took a couple of examples of things that are being discussed just to let you know, the kinds of things that are going on outside our region. Of course, I mentioned already the inter‑RIR transfers in the RIPE region, and APNIC is continuing to discuss removing the multi‑homing requirement from their end‑user assignment policy. And in the LACNIC region, they're talking about that proposal, registering assignments, I think the focus is about residential customer privacy, something that we've seen here in the ARIN region that was actually discussed and adopted a couple of years ago. Here's some references.
All of the RIRs do a great job of keeping their proposals that are under discussion on a specific page. You can go see everything that all of the RIRs are discussing right now at these links. And the bottom link is an NRO link, and I always plug this at this time. It's a document called the Policy Comparison Overview, and in one single document, it's kind of like the ARIN NRPM, but it's a policy compendium of all the policies at all of the RIRs. It's a nice document. It's updated quarterly. And, for example, if you just want to see does AFRINIC have an end‑user v6 policy, you can go to this document, go to the v6 assignment section and see what that policy is at all of the RIRs, and it will hopefully give you the answer that you're looking for. Of course, if you really want to know what the policy is at the RIRs, you have to go to their pages. And that's it for me. Thank you.
John Curran: Any questions? Any questions for Einar on the Regional PDP update? No? Thank you, Einar.
Leslie Nobile: Good morning, everyone. Okay. So this is the Internet Number Resource Status Report. It shows the statistics of all five of the RIRs in a side‑by‑side format. We update it quarterly. This was updated on March 31st, so it's pretty recent data. The first slide shows the status of the entire IPv4 address space. So if you start at the top and look in the gray central registry, there were 91 /8s issued. Prior to the establishment of the RIRs, this is where most of the legacy space resides, and most of this was issued under US government contract to various parts of the world, but most of them within the US where the early growth of the Internet began.
If you look at the green, not available, there are 35 /8s that are in use by the technical community and are not available to the RIRs or to IANA to issue to the RIRs. And obviously the big red IANA reserved, zero, is probably a very significant one. There is no unicast space in IANA for them to issue to the RIRs at this point. It is completed as of last February. And the RIRs themselves in blue have a total of 130 /8s that they're working from, and you can see below in the pie chart below, APNIC has 45 /8s issued by IANA; RIPE NCC, 35; LACNIC, nine; AFRINIC, five; and ARIN, 36.
So this is a new slide we just added to show the available IPv4 /8s in each of the RIRs. Obviously this is going to change rather quickly. So it's fairly recent right now, but it won't be for long. Looking in the gray is ‑‑ AFRINIC ‑‑ right. Sorry. They have 4.19 /8s available and yellow is APNIC. They are down to .94 /8s, and that's as of a couple of weeks ago, remember. ARIN, 4.98 /8s, although we checked our Web page and it says we have 4.95 at this point. In red, LACNIC, has 3.73 /8s available. And in green is RIPE, and they have 2.48 /8s.
This slide looks at IPv4 address space issued to our customers over the years. And we went back as far as 1999. So this is about 13 years' worth of data. And early there was fairly clear growth. Pretty steady. But then it got a bit sporadic, and the most significant thing about this is you can see in the later years from 2008 on most of the growth in the v4 space was in the APNIC region. In fact, in 2011, in the first quarter of 2011, APNIC issued six /8s in total. Just in the first three months. And you're looking in the first quarter of 2012, let's see, RIPE is issuing more space than any of the other RIRs, followed by LACNIC. So there's a slowdown in the ARIN region.
This is a cumulative look at the space how much RIRs have issued over the years since 1999. RIPE has issued a little over 32 /8s; ARIN, almost 28; LACNIC, almost seven; AFRINIC, a little over two /8s; and APNIC, over 44 /8s in that 13‑year period. This looks at ASN assignments. Early on ARIN was issuing most of the ASNs and RIPE somewhere around 2005 started issuing more ASNs than ARIN did and that continues today, that trend.
This looks at again the cumulative total, how many ASNs we've all assigned in that 13‑year period. And RIPE has issued more ASNs at this point than any of the other five RIRs. This slide looks at the 4‑byte ASN assignments. It's kind of interesting because all you really see on this slide is RIPE, LACNIC, and APNIC, in those colors, and those three RIRs issue 4‑byte ASNs by default, whereas AFRINIC and ARIN issued 2‑byte ASNs by default. We started with the lowest numbers and we go up to the highest numbers. And they did the opposite. The reason ARIN did that is because we're finding that our customers are having a lot of problems using the 4‑byte ASNs and they keep trading them back in. We decided to use one pool and start lowest to highest. And this is the cumulative total. It shows how many in total each of the RIRs have issued, and RIPE has issued more 4‑byte ASNs than anyone followed by APNIC and LACNIC.
This is the total IPv6 address space. You can see that a /3 is carved out by the IANA for the RIRs, the global unicast space, to use right now. A single /12 was issued years ago. It was carved out, and it's got bits and pieces issued. Mostly it has the five /23s that each of the RIRs received. We each worked from one single /23 initially, and then in October 2006 there was a global policy and we each received a /12. And I believe most of us are still working from that same /12 at this point.
This shows IPv6 allocations from us to our customers who are ISP customers, and you can see most of the v6 growth has been in the RIPE region. There's the cumulative total, the total number of allocations that each of us have made to our customers. And, again, it just confirms that RIPE has issued more allocations than any of the five RIRs. And this is IPv6 assignments from us to our end‑user customers. And RIPE and ARIN assign more IPv6 space to our enterprise end‑user customers than any of the other RIRs do. This is also a new slide we just stuck in here. We wanted to look at how many of our members actually have both IPv4 and IPv6. And the numbers kind of vary, but everybody has ‑‑ all of our numbers are less than 50 percent.
In the AFRINIC region, 31.65 percent of their members have both v4 and v6; in the APNIC region, a little over 45 percent have both; in the ARIN region, about 37 percent of our customers have ‑‑ our ISP members have both v4 and v6; LACNIC, 42 percent of their customers do; and in the RIPE region, 48 percent have both v4 and v6. And this is just links to the stats, if anyone is interested in looking at them. And that is all I have.
John Curran: Thank you. Any questions for Leslie? Remote questions? No? Thank you, Leslie.
Paul Wilson: I've got a brief report from APNIC here. It will touch on a few topics that are of interest, I think, to everyone here. If anyone would like to ask some questions or discuss any topics further, then please do corner me at question time or afterwards. Okay. The topic on everyone's lips I think is IPv4 exhaustion. So I thought I'd spend a little bit of time on that. We've just passed the one‑year anniversary of exhausting the available IPv4 address space; that is, the address space that we were allocating under the conventional system for infrastructure.
We've still got our final /8 policy in action now, and that's sort of the rationing policy that gives ongoing access to small blocks of IPv4. Hopefully for quite some years, since it's a full /8 and the allocation within ‑‑ from that block is a maximum /22, so do sums, and that's about 16,000 allocations available. The most important thing from our point of view, though, I think was in the run‑up to the exhaustion having a really well‑defined process in stages for reaching that and carrying on through that point of exhaustion. So we defined stage one as the one that we had been in for years, which is normal allocations. Stage two, we reached a certain point, and then modified our evaluation process to essentially be much more systematic and predictable in the sequencing of allocations.
So it's not so much that anything about policies changed, they didn't, but what we did was we serialized every request that came in very strictly. Instead of dividing requests up amongst Hostmasters, we had the entire Hostmaster group collectively review every request that came in, do that in order, and also respond to those requests on fixed time frames. So, in fact, there was no sense in which two allocations could come in in one order but be fulfilled in another order, in the reverse order, unless, say, one of them had to go back for further information. So we were very aware of the risk of hitting the endpoint where we would be saying no to a whole bunch of allocation requests and having legal challenges or any kind of major upset at that time.
So that Stage 2 ended on the 15th of April last year, and at that time we had 180, just over 180 requests in the queue. And so that was potentially 180 disputes from people who were not receiving what they were asking for. Only six of those went to any kind of escalated claim against us, and those were resolved within a matter of weeks. So we didn't actually escalate anything to a legal level at all. And I think that really was a huge success for us. And it really came about, very much through this very strict process, which we exposed to the membership quite early on as well so everyone knew what to expect.
And, as I said, we're going onwards in Stage 3 now with a maximum total allocation of a /22 per organization. That can be made in more than one allocation if someone only qualifies for a smaller amount and wants to receive more later. But /22 is the maximum that anyone can get. They're all coming from 103 /8. Okay. Here is the rate of delegations that we're making for all resources. And you see the peak in April 2011 there, which is where we hit a peak in that month of nearly 300 allocations in the month, and 180 of those were allocations that were expected to be larger. But in fact it's fairly obvious that when we said no to each of those 180, we offered them a last /8s delegation of up to /22 if they qualified. And I think everyone predictably accepted that.
We did get a peak in April, and since then we've been making delegations on to that policy, which you can see here. At the moment, in a fairly steady state of 60 or so per month. Okay. The second big topic on the agenda here is IPv4 transfers. So since November 2011, the APNIC policy was changed so that our basic transfer policy requires demonstrated need to be ‑‑ requires need to be demonstrated before transfer can be approved. And the way we've implemented that is to provide a preapproval system so that someone who wants to have a transfer approved comes to the APNIC interface and goes through what would have been the conventional allocation request process prior to exhaustion.
The Hostmasters allocate ‑‑ the Hostmasters evaluate that request and what they approve then is not an address space allocation obviously but a preapproval for a transfer to be made. So that then gives the holder or the recipient the ability to go out and find that address space if they can and to be able to transfer it reasonably quickly once they found it, and that preapproval is valid only for one year after that time. It has to be renewed.
The other thing we're working on in this space is a broker/contractor agreement that is a binding contract with any brokers who we work with in any way in terms of recognition or referral or listing or anything, which requires them to agree to comply with all APNIC policies and other RIR policies in all transactions. And so if there's a broker who's happy to do that, then we're happy to see them actually operating as facilitators to help people who need address space find it from people who have got it available.
So interregional transfers. We've got the policy that was proposed as No. 95. It was implemented in August last year. But it's a pretty lonely policy at the moment. It hasn't been used at all yet, obviously, because it needs to interact with a corresponding policy at another RIR to allow a transfer to actually take place. So there was some progress in those directions at the RIPE meeting last week, which I guess we'll hear about, and the topic's coming up this week here. So we're all interested to see that, I think.
So the rate of transfers. We've got two types of transfers now. Mergers and acquisitions which have been an ongoing administrative process of simply taking address resources from one holder to the other in cases where there's been a merger or acquisition and no other change. But the more conventional ‑‑ the new IPv4 transfers have come along. We had a peak of 20 transactions in one month, which is a pretty low peak, I guess. But that month corresponded with the implementation of the demonstrated need. So I think to the extent that's a rush, there was a bit of a rush in September last year where people, I guess, may have wanted to avoid the extra administrative burden of the demonstrated need policy. And since then while we had nearly that many in January and the normal rate is 15, 10 or 15 a month.
Okay. Moving on to other activities. We've got a process at APNIC called Resource Quality Assurance, which we implemented during the time of the final allocations from the IANA of IPv4 space where we were sort of scraping the bottom of the barrel in terms of IPv4 blocks that may have had some prior use or some problems. APNIC was lucky enough to get one /8, which was a pretty big challenge in terms of analyzing what was going on there, and Geoff and his team did that work with help from quite a few others, and found that, for instance, 18.104.22.168, if you were lucky enough to be allocated that space and put it onto the advertising of the routing system, you would be attracting about a fair bit of traffic to that address, constant.
So if anyone wants it, it's up for grabs. But in different places due to other strange prior uses and also bogon filters and that sort of stuff, there have been quite a few issues. And although that process of checking blocks before they're allocated from the IANA is obviously now over, there's the need still to keep this process up in the case of transfers and any identified problems.
We did a big Whois cleanup, got rid of 150,000 unreferenced objects, fixed 50,000 or so errors, and we're campaigning to have the mnt‑irt object maintained in the APNIC database as a result of a policy that was implemented a year or so ago. Outreach activities on RQA is something that's going on regularly as well. We've moved all of our training into an area called learning and development and recruited Philip Smith ‑‑ you may know him ‑‑ to head up that area last year. Big focus on IPv6. Also on eLearning, online delivery, and corresponding to that as well is training lab that we run that's got a whole stack of routers that can be accessed remotely.
It can be set up with v6, with 4‑byte ASNs and a whole topology that allows trainees to access routers to set them up and play with them. A bunch of training last year. Up to about 3,000 participants total trained in that year, including a whole load of them in online eLearning courses. The APNIC R&D activities are now being bundled under something called APNIC Labs, which is under Geoff Huston as well, of course.
Biggest achievement last year, I think, was development of this IPv6 capability measurement which corresponded first with the World IPv6 Day in June, but is ongoing since then. There's a big data collection activity with most of that data coming thanks to Google, from a pretty clever Google Ad‑based bit of code. But also snippets that enable specific websites to initiate this capability monitoring on their own visitors. And we're getting 600,000+ measurements coming in every day, which tell us a lot about what the actual end client is doing and able to do with IPv6.
The IPv4 address report is the ongoing analysis by ‑‑ under Labs of the IPv4 free pools around the world. You can see Labs and the Labs blog, which is known as Blabs, at those URLs there. IPv6 program. This is our outreach program for IPv6 adoption and understanding. Throughout the region, there's a lot of different events that we attend throughout the region. We provide the Secretariat for the IPv6 Task Force, which is the regional task force on IPv6, and we do a lot of work with governments as well, with regulators, policy makers and others on technical issues, and particularly on deployment, capacity building in developing countries.
And we're working with ITUD on some workshops coming up for that kind of support for developing country capacity building in particular. And a whole bunch of IPv6 governmental events listed here as well. With the rest of the NRO we're involved with the IPv6 ‑‑ sorry, the Internet Governance Forum. So there was one, the sixth event, actually, was in Nairobi last year, the seventh event coming up this year. I guess you've all heard about these from different presentations at these meetings.
We've got regional events that are fairly important in that process as well. There's also something called the Multistakeholder Advisory Group, which had been attended by Cathy Handley of ARIN previously. And Raúl Echeberría, myself, and Paul Rendek from RIPE are appointed to that group from this point onwards. Thank you, gentlemen. Information Society Innovation Fund in our learning development area is a small grants program for Internet development and innovation in developing countries, in particular in the region.
That's something that APNIC has been doing for quite some time under funding primarily from a Canadian development aid organization, you may have heard of it, IDRC, the International Development Research Centre, but they've actually expanded that in this year, so we have a joint program with LACNIC and AFRINIC as well, and we've got 1.3 million from IDRC over the next two to three years to support those programs. But we're also looking for, as we've had in the past, partner funding from other groups. So it's been supported in the past by ISOC, by UNDP, by DotAsia and others. So that's coming up as well.
Second to last is our 2012 Survey. We do a comprehensive member and stakeholder survey every two years. And our next one is underway right now. So that's a pretty serious exercise. We've got a couple of independent consultants who are running focus groups. They've done 17 meetings in three different economies of the region. They're focus groups that aim to identify issues and finalize the survey process itself. We've got to be launching the online survey form fairly soon, and it's open to members and stakeholders in the region and outside. So anyone here who would like to contribute anything to the APNIC survey will be able to do so. The launch is coming up, and the report from that survey is delivered to our executive committee, the Board of Trustees, more or less, in August, in our next meeting.
Speaking of which, coming up in August is the APNIC 34 meeting in Phnom Penh in Cambodia. We've got a new extended week, thanks to Philip Smith and his team, for an extra five days of intense training happening at that meeting. It's much like what happens at the APRICOT meeting, the next of which is in Singapore, and that will be the site of APNIC 35 as well. So all welcome, and details online there. And that's all. Thanks.
John Curran: Thank you. Any questions for Paul?
John Curran: Thank you, Paul. Okay, next up we have our morning presentation, one of the more interesting topics. This will be Geoff Huston, and he'll be talking about today's mobile Internet -- R.S., go ahead.
Robert Seastrom: Is this on? Somebody in this room who has an Acer Aspire laptop ‑‑ I think it might be an Aspire ‑‑ with an IPv4 address that ends in .156 is running a 6‑to‑4 rogue RA, and I would really appreciate it if they would stop running a rogue 6‑to‑4 RA.
John Curran: That's IP address ending .156? Check your IP addresses. If you end .156, that's you. We can always send MAC replies to help you out if you can't address this.
Geoff Huston: Thanks, John. Good morning, everyone. My name is Geoff Huston. I'm with APNIC, and my job is chief dreamer over there. I'm doing a presentation that I originally did some ‑‑ a couple of months ago in India. But, interestingly, there's really not much difference between India or here or anywhere else in the world. Almost every single one of you have now moved into the mobile Internet. And you kind of wonder: Where does it go from here? What's happening and where is it leading?
Most of you had a shower this morning. You turned on the tap. Out came water. You never thought about it. It's amazing the amount of technology that goes into making that happen. The metallurgy, the idea you can form metal into pipes. You need to extract metal out of rock. Let alone the hydrology. The whole issue of how to make this damn thing work that wherever you are, almost all over the planet, but certainly in this part of the world, you turn on a tap and out comes water. And you don't think about it. You have no idea of the extraordinary amount of technology that actually went into making that happen.
So when our kids or our kids' kids look back at us and say, "Did it work? Did it succeed? Is what you were doing effective," the best answer I would give is: If you don't notice you're using it, it worked. If it disappears and just becomes part of your life, it worked, things that weave themselves into the fabric of everyday life.
So if you look at that, the next question is: Well, what are we doing with these iPad, e‑style, you know, Google Android‑style devices? How should we look at this? Because a few years ago everyone had those little pocket organizers. They didn't work. The Apple Newton, that was a disaster. Is this one going to be a long‑term win, or just a technology fad? What are the events in our industry that make profound change? Stuff that becomes invisible. Right? So I want to sort of look at mobile computing in a much bigger context.
I love this photo. Absolutely love this photo. Which city is it in? And the minute you look at that you go, Shanghai, isn't it? No. New York. Somewhere in New York there's a shop that does the entire communications, computing and digital technology, go in there, all your answers will be found in that little shopfront over there. Just over there.
So, yes, what I really want to do, though, is figure out where this came from. How did we manage to get to the point where we've got a computer in every pocket? Our history is remarkable. This is one of the earlier computers, ENIAC. I think it was a local from somewhere on this continent, wasn't it? This is terrific. Where is the program? It's in the wires. The way the thing is wired up is the way the damn thing actually works. And what happened with the other half of the wires? The ones at the top, that's power. You haven't seen power until you've seen this.
Must have taken a day or two to boot it up. And of course the thing has its own room. In fact, I suspect it has its own building. And I suspect the power building is just next door, because this thing used power like crazy. And that little man there, I'm not sure if he's the programmer or the maintenance engineer, but I'm sure he's one of many hundreds of people humming around this box to make it work. This was real computing. This is 1946. So, you know, we're inventive creatures. Ten years later, the style guys have come to town.
So this is the offering in 1954, SAGE. Again, I think it was a US‑based thing. Of course, it's still using valves, but they look sexy. This stuff has had the imprint of design all over it, and they managed to embed the wires sometime behind the facade. What's that a photo of? We always talk about core memory. But none of us use it. That's core memory. And if you get out your electron microscope and have a look, you'll find tiny little coils of wire because that's how it was stored, around tiny little magnets. This stuff costs the earth, by the way, the annual GDP would take a dent whenever you built a new computer. And you certainly couldn't buy them.
Let's go a bit further forward. Because we now get into the '60s and all of a sudden computing is not a really big thing where you have one per country. It's now a business thing. And now computing actually has a bit of a profession. You can tell he's a professional by that very natty‑checked jacket that he's wearing. And of course you notice which way he's facing, because, I love this, he's not facing the keyboard or printer. Oh, no. Real computer operators face the DIP switches because that's how real operators program these devices. But of course he's sitting inside a dedicated room. Dedicated air conditioning. This is an environment that was constructed around the computer, apart from the dress code. That's awful.
Then we move on again another 10 years, and all of a sudden again the style guys are out there. But this was the latest and greatest in 1976. This was the big, big, big, big machines, the things that Los Alamos Labs used and a whole bunch of other folk to really do computing. That's interesting. And I love the leather seats. That's to hide all the water pipes, because this one was water cooled. This is amazing. This is the epitome of technology.
In fact, Apple used this to design their Macs and the CRAY folk used Macs to design the next CRAY. Because at the same time as this, something else happened. As well as building magnificently big iron in big machine rooms with big everything, a bunch of folk just a little bit south of here were busy turning computing from business to consumer electronics.
Evidently, if you have one of these, I don't know why you're sitting in this room because they're worth so much you can retire. The original wooden Apple 1, complete with fancy veneer. This was amazing. A, because it's got lousy design at that point. They really needed to sharpen up their act, but this revolutionized, again, computing, because you and I could afford it, all of a sudden from millions of dollars to hundreds of thousands of dollars to mere hundreds if not a couple of thousand dollars. And they didn't stop because computer devices just got better. I had one of those. I'm sure most of you did if you're old enough, and if you're younger, your older brother or sister or someone had them, because everybody had them.
They changed computing. You didn't need to learn JCL. You needed didn't need to learn this obscure language, dollar, dollar, hash, hash, run, dollar. You just pressed the mouse. All of a sudden, again, this magnificent leap that what was going on is that the machine was now becoming part of how we think. All of a sudden the visual components were important. This wasn't just a printed page. It looked like you could see into, not the computer ‑‑ that was starting to disappear ‑‑ you could see into the document, into your work, into the application.
All of a sudden it looked a little bit like your desktop. Still does. I'm sure some of you have many hundreds of icons on your desktop they way you have many hundreds of things on your desk. All of a sudden the computer starts to disappear behind that amazing interface. What a legacy. And computing keeps on changing. Ten years forward, what's really changing is the underlying chip industry. All of a sudden they mashed the entire thing on to one chip.
What's going on ‑‑ and I think this is the 3 ‑‑ sorry, 386 or 686. It's got the CPU. It's got the buses, it's got the registers. It's actually doing full 32-bits at that point. And it takes almost no power at all. Which reminds me the latest Androids are coming out with quad core. I want one. All of a sudden computing and computing processing capability is becoming a commodity. It's really easy to get phenomenal power into tiny packaging.
And then all of a sudden you go to Apple's iPhone. It's only that big because of the battery. Because what's inside it is actually five basic chips. All of a sudden it has the computing power of a laptop and form function that fits comfortably in your hand. All of a sudden this is a full‑blown machine, but it's a machine on our terms. It's got a browser. It's got a full set of multimedia capability. I sort of say full set, because now it doesn't do flash. Whoops. And it doesn't do WAP, but that's a feature because WAP sucks. But all the rest of the stuff is actually on this device. Inside those few small chips is everything you ever need to do.
This is amazing. This is now completely changing the world. The Internet is being transformed like nothing on earth. Because I suspect that that device is a device that finally says we've made it. We're becoming invisible. We're bearing down into the fabric of our lives. This kind of massive change, and you can see it on all kinds of incredibly subtle but transforming ways. When you go home, what does it look like? Like that. All of you have one of those. A few screens. A dedicated space where you have your machinery. You might pop your laptop there. This guy's got a desktop. But think about what he's built here. He's built large view screens. He's got privacy and quiet because it gets distracting. He's got his own lighting. He's got reliable power. The Internet comes up on a wire, and look at that highly comfy chair.
He goes, or she, sorry, to the computer. It's an activity. It's like going shopping. You go to it and all of a sudden, look at that, there is no other distraction. All of a sudden when you're there, the environment is completely immersive, which is what I complain about to my kids when I do that. But you see we've created that way, but is that the way of the future, or is this old stuff?
I'd like you to look at this photo. Hong Kong train. They're using the Internet, too, on their way to work. And it's incidental. You don't go there. It's part of what you do. She could be checking the mail, she could be document editing, I don't know, you don't know. But all of a sudden it's battery‑powered. It's operated with a thumb, or if you've got one of the latest Macs, it's operated with your voice with Siri, if they can ever understand you. It's hand‑sized. It's built around convenience. But, more to the point, it's trivial. You don't go to the Internet anymore. It's kind of there in your hand all the time. You never connect. You're always connected.
And all of a sudden then there's that transforming event, because now the Internet isn't an activity, it's part of all your other activities; it just disappears. So let's kind of see how big this is. Let's look at some numbers. How many people on the Internet today, if you believe the ITU, and there's no reason not to in this particular snap, there's probably about two billion others of us outside this room happily typing, talking, doing whatever they do, chatting away on the Internet.
Two billion in ten small years? That's not a bad achievement. We've come a long way. There's a few graphs up and to the right. This is cool. And we can say that this is terrific. But actually compared to the telephone, we've still got a bit to go, because there are five billion ‑‑ five billion ‑‑ mobile phone users. And, interestingly, between the developed and the developing countries, there's almost no gap. In this style there are almost the same. Five billion mobile users, and the folk with iPhones and iPads already within a small number of years, within four, we have sold 630 million of them.
Don't forget the size of the IPv4 space, 4 and a bit billion. And we've sold 630 million of these tiny little mobile phones. This is amazing. And they use the Internet differently. 1/10 of the data then wired. There are not actually massive data hogs. What they actually do, I think, is quite smart in the way in which they transact. They're not intense, but they're useful. And there's a lot of them. If you can read behind the absolute blindingly white‑yellow, it's clearly yellow, in 2011 270 million units shipped. They say they're all made in China. You know how much labor cost goes into making an iPad? Eight bucks.
You can make them anywhere, because to lay the component is down to three minutes. All of a sudden the industrial age takes on an entirely new dimension, because this is a digital industrial age, and, quite frankly, cheap labor doesn't matter anymore. This economy is entirely different. You can make these things for under $90. With Android free software for this stuff you can assemble this within a week if you really wanted to. And you don't even need the create content, because everyone's creating content it's called the Web and it just works everywhere.
So all of a sudden, if you're making chips, you're Intel, who is your biggest market? The mobiles. All of a sudden it's low‑powered chips that actually conserve power. It's not the big, hunking, great, massive water‑cooled chips that make any difference at all in today's world where all of a sudden the world is completely transformed. So who plays? Android. About 20 percent of all the mobile devices shipped in 2011, and, quite frankly, folk love them. That one's going to go up.
And the fact that a whole bunch of Asian manufacturers including HTC, Samsung, and so on, patent wars notwithstanding, are capturing amazingly large part of the market. And it goes into tablets and large screens. Evidently the latest Kindle has actually come up with a hermetically sealed version of Android, of its platform. And, of course, Apple, the benchmark of this. Interestingly, it doesn't have the bulk of the market, but it has the bulk of the money. Because these guys have an amazing margin, 27 billion in 2011. And at the time I did those slides, they were going to make $40 billion of profit by 2015. I think they'll get there faster. Who owns a Blackberry? Get rid of it.
Geoff Huston: And who owns a Nokia? You should have gotten rid of that already. They've just gone broke. Their last quarter was negative. All very sad. So, yes, the market is changing certainly, and some are winning and some losing. Sales projections, no matter which way you cut it, though, the numbers are big. A third of a billion per year just simply growing monotonically, and whether it's Androids or Apples or Symbians or even dear old Windows, the numbers are certainly there. And what happens to all this? Some companies are getting big and even bigger. And part of this is this design innovation that says it's actually not the technology. It's not the technology, it's understanding us.
It's understanding how you do things and just intruding a little bit of a help. What's the weather like today? What am I going to wear? Oh, I'll just look it up, as I walk out the door. Should I take my umbrella or not? Incidental questions with incidental answers is actually what makes life helpful. And, interestingly, these numbers have helped amazingly. Look at Apple. Quarter 3 2010, 8.4 million iPhones. A year later, almost triple. That's growth. We always thought doubling every year was pretty cool. Apple is cool, cool because tripling is much better than that. Even iPads tripling in a year. So Quarter 3 profit 2011, a respectable 7 billion.
The next quarter, what's the richest company in the world by share price, shareholder value? And the answer was an oil company. Exxon Mobil. No. $600 billion, it's Apple. Largest company in the world. Quarter four, they were busy. 37 million iPhones were shipped in Quarter four last year. 50 million iPads $30 billion of profit. This is actually what's changing the Internet. If money has an impact, this is where the money is. And, as you see by the projections on money, these multibillion dollar industries will dominate the Internet. The wired world is just so yesterday, and when Apple really did say in March we're living in a post‑PC world, it wasn't just a marketing catch. It's true. It's over. Because computing is now something that happens all the time anywhere. It's just convenient.
So what's the technology that's made it so convenient? How have we managed to transform this? Where is the valves? This is a fascinating history, again, of money. Because the first efforts that really transformed the world ‑‑ and it was European, I'm sorry ‑‑ was actually GSM. Because it was GSM that came up with a uniform technology across a whole bunch of operators, both in Europe and Asia, and eventually over here in this continent as well, that actually set up a digital cellular network standard. The beauty of this was it was just another couple of voice channels. You remember the early days of the Internet, we're building the Internet on top of the voice network. Exactly the same over here. They just built it over the top of the voice network in mobiles. 16 to 32 kilobits a second. Latency was high because it had a whole bunch of electronics either side. But if you wanted it to go faster, you just knocked some voice channels out of the way.
So it certainly was elastic. And it really did transform stuff. But there was only one application that was on it. Does anybody remember WAP? Good. No, no, no, you're not supposed to. It was a disaster. Do not go there. It was really crap. So, yes, WAP was crap. It's just kilobits per second. 3G is what we're after. This is high speed. HSPA, High Speed Packet Access. This was actually coming out of Qualcomm and others. It was a preversion of Wideband CDMA. But the data rates are really quite respectable.
You're getting up to 20 megabits a second on the down and 6 megabits up, and really quite quick, because they discovered what the modem guys had discovered ten years ago; that if you muck into Fourier ‑‑ fast Fourier transforms and play around with phase space as much as amplitude space, you can cram bits in like you never thought.
And it's all just computers. They can do this and they did. So this is looking actually quite acceptable. And compared to the stuff on the wire, it's okay. You might notice it slightly so, but it's all right. So we then started to evolve, because we can, and some carriers started running HSPA‑plus, which gets up to around 100 megabits a second. And that's basically by using multiple antennas and doing things in parallel, because the other strength about computing is you can jack up the clock. But if you really want to go fast, just dump in two or three or 10 or 50. So now you're getting up to 10 megabits per second and the performance is pretty sexy.
But, no, we can do better than that, because now all of a sudden we're rolling out LTE. Now, this one is different. It's not data on voice. This is transformational, because the mobile industry, data was just there as a little bit of a joke. Look at AT&T on mobiles. What's their data network like? Shocking. The quality is shocking. They don't really care. It was all about voice. But this technology, it's all about data. And it's all about mobile data for data's sake. So now the theoretical downspeed performance is a blistering 326 megabits per second. But basically the footnotes do say, and it's true, you have to suspend all the laws of physics as we know them to get that speed. But if you're prepared to go that far, it will come with you. Normally a lot less than that. Achievable normally around about 10 to 12 megabits per second, but over wideband radio. That's actually pretty sexy. That's pretty cool.
And the internal stuff, you can't see a spot of a voice circuit. It's IP all the way through. All the way through. So now the game gets really interesting. In the same way as around seven to eight years ago, when we really wanted to go fast, we got rid of all of the residual time‑to‑vision multiple access in our networks. We got rid of data over voice and started building IP from the photon up. These guys are now building IP from the radio frequency wave point up. And that's interesting. That's a whole new set of economics. So let's have a look at how this impacts the total network. Let's go back to our core business in addresses and see how this has an impact on the addressing side of things.
I think you've seen various incarnations of this, and I'm going to add another. But what I'm really saying in this is we're now up to sending out to the planet 250 million addresses in IPv4 per year. And the only reason we didn't achieve 300 million in 2011 is really simple: We ran out. All of a sudden Asia's sitting there going urrg. Guess what happens on August the 12th? Europe sits there and goes urrg. Because they're going to run out then, too. And that has a really big impact. That changes the way in which we look at things. Where did they go to? This is a where they went to, 2009, 2010, 2011.
There used to be a story around the Internet around ten years ago that China had no addresses, that even a single university in America had more addresses than China. Well, we fixed that. As an industry we did fix that. 50 million in 2009. 45 million in 2010. And, albeit, we ran out in 2011. We ran out. So in the first four months, 53 million addresses headed to China.
The US is interesting. And I think that's because of you people. When you changed your policies in early 2011, the industry sort of changed with it. And whereas before you were doing around 40 million new addresses per year, because, quite frankly, that's how many iPhones and mobile thingies you were selling, and that was sort of tracking AT&T and Verizon and Sprint's entry into the mobile world. It stopped. And I don't know why. I wish I did. But even more importantly, I wish you guys did, because this is your industry. This is your neck of the woods. And I think you really should have an answer as to what's going on inside that industry.
A few of the other surprises out there. Russia, maybe that's not a surprise. Germany, Brazil. And Australia. That one surprised me because, quite frankly, we are 22 million people at the ass end of the South Pacific and we're doing 9 million addresses one year. Go. But, yeah, this is all about where the countries are. Let's go down one level. This is the largest allocations in 2011. And I put an asterisk beside the folk who are obviously, obviously doing mobile Internet. AT&T. They sell mobile things. China Mobile. That's a giveaway. And the Brazilians, it's actually the entire country of Brazil. Indonesia got 6 million addresses, but not just Indonesia, cellular means what it says. It's the cellular folk. KDDI Mobile. AT&T Mobility, what a giveaway. All of these folk, Telekom Deutschland, mobile.
So out of those 18 carriers who got one‑third of all the addresses last year, I'd actually say all of them are mobiles, but the ones I put a star beside are obviously mobile. I love Morocco. Someone's right there out there in Morocco doing brilliant things. I hope they have a ripper of a network. Where do we go from this? Where is all this headed? This is fascinating. The last 15 years telecommunications industry has been gloriously lazy. Outside of this part of the world, they didn't have to think. We just did what you did. We bought gear from Microsoft. We bought gear from Cisco. We bought gear from your suppliers.
You earned a lot of money. We didn't have to think. It was a great deal. And, interestingly, this industry isn't the world's smartest industry. We do play follow the leader a lot. And we're very used to following leads and get addicted to it. But the world has just changed. We can't do in Asia what you're doing in North America, because we don't have the addresses. We meant to run CGNs or meant to do v6. Where's the lead?
Here you're not doing anything because you don't have to. Even in Europe you're actually going to strike the same kind of issue, because most of the European attempts ‑‑ does anyone remember OSI? Didn't work very well. And we've all of a sudden adopted this lead from elsewhere. So to look at where we're headed is a very fundamental question, because to get it right is difficult. So so far we've done it the lazy way. We've just chewed up the last few IPv4 addresses. Add demand in the Asia region alone in terms of consumption is at least 100 million new addresses per year to fuel growth.
Globally this industry is addicted. Globally our demand is a third of a billion addresses per year. Apple isn't going to stop producing them. They can't, and they won't. So how are we going to fuel this? More NATs. How big does that get? Because if you haven't stockpiled addresses by now, it's too late. So let's talk a little bit about tomorrow. I've been doing some minor plots of this. The red line is basically this industry's demand. We're in the consumer electronics business, and demand is like a machine. Once you start it, you can't stop it. This is an iPhone 4, and I'm feeling it's kind of old, I need a new one, I need a 5, when is it coming out? All of you feel like that, don't you, and your kids and your pets and your car and your light bulbs and everything else.
We get addicted because it's consumer electronics. That red line isn't stopping anytime soon. It's an inexorably march upward. The blue line is our ability to service it. And even this year there's a gap. In 2012, the gap is bigger, because as Europe goes to the world, we're not going to need it. The yellow line is the accumulation of demand. The folk we haven't been able to give addresses to. The cumulative gap. And within two years it's one quarter of the entire v4 address space. That's a massive shortfall. We can't do that with NATs. We're going to have to do it in v6. Some folk are right, right, right there. If you bought one of these latest things from Samsung and running Android, you've actually got IPv6 support in the chip that does radio.
And if you're using some apps and not all of them, nothing even does it. The iPhone sort of and sort of not. It does v6. And if you turn it on here in this room and get onto the ARIN network, your iPhone does v6. And it's great. Walk out the door and go to ‑‑ what is it ‑‑ Bell Rogers Canada fee, they're not very v6‑aware, are they? But even if they were, your iPhone wouldn't pick it up because it doesn't do v6 in the radio. It just does it in the WaveLAN. And Microsoft, the folk who 15 years ago said the Internet was a passing fad, are still saying that v6 is coming anytime soon, possibly in the Apollo release they promise, truly‑rulely, hand on heart.
But the reason why the vendors haven't done much is that the operators have done even less. And this industry, as well as being dumb and following the leader, is not very good at communicating. Who's doing v6? And you talk to a lot of people one‑to‑one and they're going: We're doing it, but it's a secret. You know, for God's sakes, say so. We think T‑Mobile is doing something. Cameron Byrne has been very good about saying what T‑Mobile are doing, and Verizon came out with some press releases about all their supply line had to be v6, but that was two years ago.
So they're running this LTE network, but I have no clue precisely where 6 sits in that. And I wish they'd be more open. But it's not just an American disease or a North American disease. Everyone is kind of: No, we're not going to talk about it. So it was a breath of fresh air to go to the RIPE meeting in Slovenia last week. Why? Because they were handing out SIM cards. Useless for my iPhone, unfortunately. Why? Because it was v6‑only. This was a real experience. There they were, Mobitel in Slovenia, and their network is full v6 and v4 was the one you had to pay for that week; v6 came out free. This is cool. And we believe that in Norway, NWN is actually doing v6. There may be more. But for some insane reason they keep it a secret.
Now, let's get back to a few numbers yet again and just remind ourselves this industry's growing at 300 million new services, new services a year. No matter how optimistic you are about carrier‑grade NATs, you can never make that fly for more than a year and a half. Don't bother. So what's your other plan? What is your v6 plan? Or, sorry, your next‑generation plan if it's not v6? Well, that's a problem. Thank you very much.
John Curran: We have a couple of minutes for any questions for Geoff.
Geoff Huston: Don't go to the bank this week. They don't like you.
David Kessens: I don't make mobile phones. We make mobile network gear. Something slightly different. You state that Verizon or LTE has announcements about IPv6. It's actually there. It's working today.
Geoff Huston: This is really good news. Get on them. Yes.
David Kessens: There's a lot of this kind of stuff where it's not really announcements anymore. It's actually just there.
Geoff Huston: It's great to see that when I go and Google it or find anything else about it, oddly enough I'm really searching for that kind of news. I actually do wish that the operators who were doing it made more of a song and dance because, quite frankly, I think they need to, even if only to convince the other operators that it's easy.
John Curran: Go ahead.
Chris Morrow: Chris Morrow. I work with Google. And this is really as just a sort of person in the audience. Two questions, some of which are heretical, I think. So why is it that the mobile phone manufacturers think that it's a great idea to put the version of IP into the firmware? Why is it not just sort of framing and shipping data? It's not a question you can perhaps answer, but it's something to think about, like didn't we sort of solve this problem in other places by saying somewhere further up we should deal with what version of IP it is and the firmware shouldn't care?
Geoff Huston: I was amazed, actually. I've been looking at the behavior of Android and iPhones in dual stack, and, quite frankly, the Android operating system is a vanilla version of Linux, whose TCP behavior was defined in 1985 and the parameters on the mobile phone haven't changed. Now, the folk who were doing TCP in 1985 are really cluey people, don't get me wrong, but none of them were building true speed on wireless. They were building it for wire. And I actually suspect you could do a better job. I looked inside the iPhone. That's free BSD and the connection parameters date back to about the same time. I'm not sure either of those vendors in terms of software stack producers have actually tuned their stuff for the wireless they're running over. I think you could do better.
Chris Morrow: That wasn't the question I asked.
Geoff Huston: I know, but it's a question I wanted to answer.
John Curran: Your second question, Chris.
Chris Morrow: Mr. CEO, could you back up like six slides to the picture where you said NAT won't do it? I just have a question. That one. Why can't NAT work? Seems to work fine today. I think the stuff hidden behind enterprise NATs is probably similarly sized, right?
Geoff Huston: So I looked at Chrome browser on a dual‑stack machine. It immediately opens up three ports in IPv4 and three ports in IPv6 to see which is faster. Six ports get open. But I was fetching a GIF. One GIF. The way we build applications these days is actually intolerant of the underlying machinery. And we've decided to make browsers frightingly fast that we're using NATs from 10 years ago where 65,000 ports was available at the home. But in CGNs, NATs are scarce, and if you start to get browsers and apps that make profligate use of the port space just so that Chrome is faster than Opera and Opera is faster than Explorer, then all of a sudden you're doing what we did in the commons 500 odd‑years ago; each browser is trying to optimize their use of a common resource at the expense of the common resource.
We're not going to solve this by building better CGNs. CGNs are truly, awesomely weird. There's a protocol called Teredo that tries to do doing NAT traversal. Anyone have a Windows machine? You have Teredo. I can make it work. It's really easy. I send you a URL that doesn't have DNS. Only 40 percent of you ever make the connection. Sorry, 60 percent. The other 40 percent die because Teredo doesn't work through all NATs.
So you have here an application, pretty simple, with a failure rate through NATs of 40 percent. And you're telling me that somehow CGNs would be better? It's the same NAT. It's the same disaster. It's the same train wreck. If this industry thinks that CGNs are going to sustain it for even two years, then I've told you before we were lazy and stupid. But if they honestly think they can make this work with CGNs, they're lazier and stupider than even I thought. Thanks for the question. Did I answer it?
Chris Morrow: That one you did answer. Really I would say some of that discussion ends up in this presentation for this slide and it makes it a lot better, as opposed to just, bam, that won't work. Well, yeah, but, you know, if they do work.
John Curran: Okay. Question here. Go ahead.
Tim Denton: Geoff, I always try to remember what you say, which is highly annoying, I'm sure, and I see in a speech you gave last year ‑‑
Cathy Aronson: He's moved on from that.
Tim Denton: Indeed. For many, Internet years ago, that says given that we've left it so late in terms of scale of the transition and the degree of difficulty with IPv4 exhaustion, and given that there appears to be little motivation from some critical industry segments to embark on this transition, will it happen at all. Now, given how I remember things, I seem to feel that what you're saying this year is that we will make the v6 transition. And is it accurate to say that your views, your hope, expectation, for a transition to v6 is greater this year than it was last?
Geoff Huston: I'd like to think we will. I'd like to be optimistic, because it's a real bugger to be pessimistic all the time. The problem is, though, that neither you nor I honestly have a clue.
Tim Denton: I know that. But you're the guy that's supposed to know.
[Laughter and applause]
Geoff Huston: Honestly, I don't. Part of this is actually a tension that is unresolved for many hundreds of years between the carriage industry and the content industry. Apple is a slight preversion, but Google is a very good example of content only. Google makes their money from delivering content to you. And you, through ads and everything else, indirectly pay for that. But neither ‑‑ the carriage industry, the folk who delivered those bids, don't participate in that economy. It's almost like you go out there and buy your bottle of water for three bucks, and here's the water company delivering megaliters of water out of that tap for cents. The carriage industry is not a happy industry. Delivering DSL to consumers for 20 bucks a month gives you one buck a month of revenue, if you are lucky, after you've paid all your bills.
So the problem is that these guys are looking at v6, going “Hang on a second. I just don't get it. I have to spend all this money to put in v6 to make Google richer. Where is it for me?” And so far I think the reluctance of this industry to go to v6 is down there inside the business dynamics. I would like to think, Tim…I would honestly like to think we can get over this. I would like to think that carriers and carriage providers can, with either some degree of enlightened self‑interest or, unless you're Greece, a little bit of state‑based inducement financially, but some kind of impetus deploy v6. Because the barrier is so slight, it's just getting over that initial hump. But it's not assured. And the other option, although ghastly, is vaguely reminiscent of the 1980s, because the other option is we start to erect barriers again.
The CGNs become biased, and there's more ports available for applications that pay the carrier attacks. That all of a sudden we start closing up the network and being very selective, the carriage industry gets paid by content. I don't want to see that. I think it's unhealthy. I think it's against everything we've done in the last decade. But I have to admit it's a possibility. So I honestly don't know, Tim. I'd like to be optimistic. I thought I was. Lighten up, guys. I mean, this will happen. But it won't happen without some effort, and I think the effort is all of us to actually make it work.
Tim Denton: I'm going to have you come visit the CRTC sometime and give us this talk.
Geoff Huston: Thank you.
John Curran: Thank you, Geoff.
Sofía Silva: Good morning, everyone. My name is Sofía Silva. I work as the Network and Security Engineer at LACNIC. First of all, about the membership. We reached 2,000 members last year. I think it was September or October. Now we have almost 2,400 members. About the resources we have…As of April the 18th we had more than 62 million IPv4 addresses, which is almost four /8s. We've been allocating and assigning a lot of IPv6 prefixes, because we have some new policies, which were approved last year, which add the requirement for those IPv4 requesters of also requesting an IPv6 block.
Regarding ASNs, we've been assigning a lot of 4‑byte ASNs, this is because since January last year we started assigning 4‑byte ASNs by default. We only assign 2‑byte ASNs when the requester explicitly says that their equipment or their upstream provider's equipment does not support 4‑byte ASNs, or sometimes we assign 4‑byte ASN and then the requester comes back and says my equipment doesn't support this. So we can change it for a 2‑byte ASN. Well, regarding Resource Certification, we've been promoting RPKI. This charts show the amount of IPv4 prefixes signed, the percentage of announced space.
Our last meeting was held in Buenos Aires. There were more than 300 participants. Six policy proposals were presented. Three of them reached consensus. These three policies ‑‑ proposals that reached consensus were ‑‑ well, 2011‑03, this is one of those I was mentioning before about adding the requirement of requesting an IPv6‑block. In this case it's for additional IPv4 requests. Then 2011‑04 adds the requirement of requesting an IPv6‑block during the last /12 block. And then 2011‑06, resource and other /12 in order to ensure a gradual IPv4 exhaustion.
Our upcoming meetings, in two weeks we'll have a meeting in Quito. We'll have a policy forum and some technical forums. And then in October we will have our policy forum and it will be organized with LACNOG, and it will be LACNIC's tenth anniversary, so it will be a great meeting. Another important new is we have new offices, great offices. That one is the view from my desk.
Sofía Silva: Yeah, it's beautiful. So you will be very welcome if you want to visit us. And that's it. Any questions? Thank you.
John Curran: Thank you. Any questions? There is no waterfront in Chantilly, I've just noticed.
John Curran: The history of the policy proposal. It started as ARIN Policy Proposition 126 in January 2011. The AC shepherds, Chris Grundemann and Owen DeLong. The AC selected it as a Draft Policy in May, and it was presented at ARIN XXVIII. The current version is the version from February, February 22nd, and you have, of course, the text and the assessment online and in your Discussion Guide. Summary. Proposal requires ARIN staff to identify customers who are out of compliance with the policy and to eventually withhold services for ‑‑ okay? ‑‑ to withhold service for those who fail to come into compliance within a designated time. Staff is to contact customers who are out of compliance with policy. Customers have 30 days to respond and 60 days to demonstrate they've begun to take the corrective measures. If either of these criteria are not met, the policy instructs staff to cease providing reverse DNS services to the customer or begin reclamation efforts after 90 days.
Status at the other RIRs. Nothing similar at the other RIRs that we could determine. Staff issues and concerns during the staff review: The term "out of compliance" is not well defined. Without additional criteria, staff will continue to interpret this somewhat liberally and apply at our discretion using our best judgment and consideration of existing factors. Only those organizations we deem to be significantly in violation of existing policy would be flagged for further review and audit. Removing an organization's reverse DNS or reclaiming IP resources will likely have a negative impact on their ability to conduct business. So worth thinking about here.
Resource moderate. Moderate. New software tools to track the deadlines. A significant increase in time and workload for the registration team, as we have the potential for real increase in resource audits as a result of this. Resource audits are not low‑effort activities. They're high‑effort activities. Could even require additional personnel, because this doesn't gateway our ability to engage in these audits. If there's enough of them that take place due to the guidelines, we have customers in similar circumstances of noncompliance, we'd want to process them all. Updated guidelines and staff training, obviously.
Legal assessment. Significant legal implications, as it requires ARIN to withdraw services that may impact innocent and bona fide third parties utilizing the resources. Any revocation made pursuant to this revised policy could result in litigation. So people have to recognize the potential impact of third parties, recognize people might be upset by that. It's not that we can't do it; the consequences, though, need to be well considered by this group. Discussion. 22 posts by 13 people. None in favor and three against.
Ranging comments included someone uncomfortable requiring ARIN to stop providing services. "If we want to give ARIN permission to do so, fine. I don't think they'll abuse it. Even use it too much. But I'm unconvinced that requiring them to do so serves a useful purpose." "A breach in the RSA is a legal issue, not a technical one." "I would simply return the point of records like this‑IP‑address‑space‑is‑stale‑or‑hijacked‑visit‑WWW.ARIN.net." Fun on the pointer text. "It would be nice if it referred to a Web page that described exactly what they needed to do to correct the situation. That is the Draft Policy introduction for 2011‑7. At this time I'll ask Owen DeLong to come up and give the AC presentation.
Owen DeLong: Okay. Good morning, everyone. First of all, at the previous meeting a lot of the discussion around this proposal centered on things that are actually part of the current policy text and not the modifications contained in this proposal. The modifications in this proposal are pretty narrow in scope. They talk about very few things.
Specifically, it attempted to address some legal concerns with Section 12.4 by changing materially out of compliance to out of compliance at the request of ARIN's general counsel, and it adds the ability to bring yourself into compliance by updating your reassignment information in addition to the option of returning space, et cetera. It provides specific timetables and uses DNS has an additional interim tool before proceeding to revocation or reclamation. So it's an attempt to actually make the policy a little bit gentler than the current existing policy, not an effort to make DNS some sort of new ability to beat people senseless.
Staff comments: Out of compliance is not well defined. That may be true. Although, their current interpretation seems to match my understanding of the community's desired result. So I think it's okay. I think the existing policy which reads materially out of compliance is even less well defined. So at least this proposal seems to be somewhat of an improvement over the current situation even if it's not perfect. The other staff comment that removing an organization's reverse DNS and/or reclaim Number Resources will have likely have a negative impact on their business. That's true in the existing policy which doesn't allow for the DNS, it just goes straight to revocation or reclamation. What's new in this policy is the ability to use DNS as an incremental step towards getting their attention.
And if the use that people are making of the address space is outside of ARIN policy, then I think the negative impact is kind of what we want. General counsel's concern about litigation from policy enforcement. That could be true under the existing policy as well. I don't see any reason it's any less of a risk or any more of a risk with this policy than with existing policy. The community needs to decide whether we want ARIN to enforce its policies or not. And if not, we need to consider the question of how do we keep policy meaningful. In terms of the pros I was able to identify, it reduces, although it doesn't eliminate, some of the ambiguity from Section 12 as it's currently written.
It uses DNS as a gentler step prior to full revocation or reclamation. It makes it easier for ARIN to give cooperating organizations additional time to comply, and it provides an incremental improvement to Section 12. I understand from the previous meeting there are lots of other improvements people would like to see in Section 12. I'm happy to help you develop other proposals to address those. But this proposal isn't about that. It's about these specific things and I'd like to try and get us to focus the discussion on that so that pro or con the AC has useful feedback about this particular proposal.
In terms of cons, from PPML, this pretty much matches the summary you saw earlier. ARIN should enforce policies only on new resource requests. Stop futzing with Section 12. Don't use DNS as leverage. ARIN should focus its resources elsewhere, and one person basically said skip the DNS turn‑off, just go straight to revocation. Which is what the current policy does.
So questions I think would be helpful feedback for the AC from the community, the reverse DNS policy in this shut‑off is really used as a final attempt to gain compliance before moving on to revocation. Would the community actually prefer we go straight to revocation. Focusing only on the aspects of Section 12 that this Draft Policy seeks to change, are those changes an improvement to the existing policy or would you prefer to keep the status quo? And are there specific changes that would make you support this Draft Policy if you don't already. That's the end of my slides, and I believe now we'll open it up to discussion.
John Curran: Microphones are open. Mine isn't, but your microphones are open for questions. Questions are welcome from the floor, from remote participants.
Martin Hannigan: I don't think ‑‑ there's still not consensus on this proposal as far as I could tell. In reading the proposal in Section 12 again, I'm not certain why we would insert what appears to be Section 3 Whois policy into resource review. Adopting such a proposal only shifts costs from ARIN and others to the network operators. Staff and legal comments also appear to be written to complement one another. Staff remarks that the definitions are weak and that enacting this could impact an organization's ability to conduct business; legal remarks that if we were to modify resources using this language, we could end up in litigation.
This adds an unnecessary risk and potentially unnecessary cost. We already have protections for the organization in Section 4 and Section 8 of the RSA as well as Section 3 in the NRPM. This proposal seems like an unnecessary complication of policy that is already generally ‑‑ excuse me, allergies ‑‑ this proposal is an unnecessary complication of policy that is already generally vague and expensive for network operators. I'd like to point out the lengthy discussion on PPML that you and John Curran also highlighted. It doesn't appear that any of the suggestions that were made were taken into consideration. I do want to highlight the fact that all of those suggestions were not in favor of interfering with services.
Let me tell you a little bit about Section 12 audits. The target constantly moves. The type of data request that is not consistent so it's hard to codify our requirements in applications. Depending upon the size of the resources held, the amount of time and expense to an organization varies as well. There was a vast difference between Section 12 audits with respect to the holder of a /20 versus the holder of a /8. And enforcing any kind of timeline is impossible to be evenly applied. Section 12 is probably an example of policy that needs the most work in this organization, but we should probably just leave alone. I strongly believe that we need to stop futzing with Section 12 policy ‑‑ that was my quote ‑‑ and move on to more important policies such as policy to support IPv6 transition. I'm opposed. Thank you.
John Curran: Marla.
Marla Azinger: I'll have to get back in line because I have more than one thing. You can go first.
John Curran: Mr. Sinatra.
Michael Sinatra: So Michael Sinatra, ESnet. I have a question regarding the staff assessment, because John said something that I don't see written here about possibly needing an additional staff member. Could you reread that or could somebody requote that? Because I don't see that written in the staff assessment here.
John Curran: It's very difficult to forecast the amount of effort that's required in the policy. With the staff assessment, it says Resource Impact.
Michael Sinatra: So that second bullet right there, if we're not changing the fundamental aspects of Section 12, why is there a significant increase in resource audits due to noncompliance with IPv6 reassignment requirements. That seems to contradict what Owen is saying, is that the policy is already there, we're simply changing it, you're making a few tweaks with it. If it's something that's going to force the staff to do a lot more work to do audits based on reassignment requirements, then that seems to contradict what Owen's saying, and that's where I think a lot of us have concern.
Owen DeLong: Where that comes in is that one of the more subtle differences of this policy, of this proposal versus the existing policy is this proposal actually makes it more of a mandate for staff to pursue these, whereas right now staff kind of pursues them on a basis of when they want to or when they're able to or ‑‑
John Curran: We presently pursue them based on when we see that we're not making progress towards compliance. We're at present allowed to negotiate with a party and say according to the existing 12.6, we can turn around and say how long do you need, six months is the default, is that enough to bring it up to spec. Under this, we don't have that free leeway, and we have specific hard deadlines at which we have to consider either DNS, pulling the DNS or revocation. So we can't space out ‑‑
Owen DeLong: You do still have the ability if you believe the organization is working in good faith to give them more time.
John Curran: Right. But we can't tell them we're going to check with you in six months. We have to check with them and verify that in order not to pull DNS if I read this correctly. So there are staff tasks that are dictated by a clock, a clock which cannot be deferred, even if it's just verifying they've made material progress in 90 days.
Michael Sinatra: Thank you for that clarification. So I'm opposed to that aspect of the policy. I'm also opposed to the DNS aspect of the policy. I think you have two mechanisms by which operators can document their networks. One is Whois, the other is reverse DNS. If they're not doing the right thing in Whois, then that's a problem. You take away only other mechanism of documentation they have, that's like telling someone, well, you're driving without a license I'm going to take the license plates off your car. That doesn't make very much sense. It's just going to hurt the people who are actually trying to enforce the policy.
So I think the AC has done a great job of trying to get the text of this policy together. I commend the folks who originated the policy. I think the intentions are great. I think it still doesn't work, and I think it's unfortunate we just don't have a good enforcement mechanism here. So I'm opposed. Thanks.
Owen DeLong: Kevin at the head table.
Kevin Blumberg: So I had a question. The revocation policy as far as staff, from a procedural point of view, why does it not allow for this as in a soft landing, in the revocation? When I have to fire a customer because they haven't paid, the last thing I do is completely delete every record of them, get rid of them all in one fell swoop. I turn them off, wait, wait, wait, the call comes in please turn me back on. Is this a procedural policy or policy issue that needs clarification? Can staff not through their revocation process have it stepped in such a way as to do this?
John Curran: Can we turn this microphone on and leave it on? So if I understand your question, it's does the existing policy give staff discretion and is a new policy needed. The existing policy gives staff discretion without putting words in Owen's mouth, one might say it provides too much discretion, hence the point of 2011‑7.
Owen DeLong: I don't know if it provides too much discretion or not. I certainly think that the proposers believe that. I'm generally in support of the proposal, but I'm not opposed to restoring more discretion to staff in that regard. I would like to see ARIN work harder at doing more. I think Kevin's question was more aimed at is there something more incremental we can do, and the problem is that really the only tools ARIN has are our DNS revocation and resource revocation. There really isn't anything in between. They don't have the ability to go turn off their route. So I'm not sure what could be done in that regard with policy.
Kevin Blumberg: I guess what I'm asking is could this be done through the ASCP process as a way to outballoon this policy rather than forcing the policy where there's definitely, from what I'm seeing, community concern about this being a big stick, lots of costs, lots of resources for everybody. Could this not be done through procedure as a trial balloon to see?
John Curran: It absolutely could be. That would require that the staff say ‑‑ that's ‑‑ I run the staff ‑‑ would require us to look at it and say we're suggesting this. I concur with the Board and we talk about the resources. The challenge is we won't do that because of the resources and legal liability. So if in this case, while it could be done, if it was apparently a good idea, we will instead only do it because of the resources that could be involved and the legal liability that could be involved if we have a clear mandate from the community. Does that help understand? I would have brought it to you guys already if I thought it was something that could be handled directly without those risks.
Kevin Blumberg: Thank you.
Owen DeLong: Are you ready again, Marla?
Marla Azinger: Yes, I think I'm ready. People woke up. I am one of the original co‑authors at the beginning of this. I'm very grateful that the community passed what is in place, because it will work and it can work. I have faith in the staff that should maybe a law enforcement report that there's a certain entity that really doesn't have the records up to date that they would pursue that and actually progress through what is already written and passed. But this next one that is now in front of us adds a lot more. One, if you remove some of these records, the DNS goes with it. The DNS doesn't stay in the database magically working for those address sets that ARIN revoked. So if staff did say, okay, if they're bad, no, they're not doing what they need to, we're pulling the records. DNS is gone at that point, too.
So, eventually, if you don't do this first step, the DNS will be gone when it needs to be gone. It's not a gentle step to remove DNS. If you're actually an entity that has products and services that rely on DNS working. So that slide that mentions a gentle step kind of made me laugh.
Owen DeLong: It's gentler than flat out revoking the resources is what it says.
Marla Azinger: The word "gentle" is in the sentence? So this is my ‑‑
Owen DeLong: Yes. Gentler.
Marla Azinger: Owen, can you just hold off, 'cause ‑‑ thank you. If this was passed, I would like everybody to look forward and wonder and ask the question how does this interplay with transfers. Because if someone is contacted and said, You're not using these, we don't think, your records aren't up to date, well, is it so sad, too late, we're now going to revoke it? Or can they go: Okay, my bad, you're right, so I'm going to go put it on the transfer list and try and sell it. So that I'm curious how that would be handled.
John Curran: I'll answer the transfer question. So a party, if we're in the middle of a resource review, there's a number of different possible outcomes. One of the outcomes is that the record actually ‑‑ the party we think is the record holder isn't the valid record holder completely. In which case, they're not going to be able to do a transfer because we have to validate it as the first step.
Marla Azinger: I don't even consider that in the ‑‑
John Curran: If it's simply a case of lack of delegation of information, yes, they could transfer it without the delegation record information in place, that wouldn't interfere, but if they're not the appropriate record holder, that would definitely get in the way.
Marla Azinger: What if they're a record holder that has excess space they have not used and they know they haven't used it, and now it's been reported that they're not using it. ARIN asked them about it, "Get your records in place or we're going to reclaim it, but they say, "We're not really using it, so we don't have records to get in place but I want to sell it now"?
John Curran: Any party that has resources can transfer them. That's a way of getting into compliance with required utilization levels.
Marla Azinger: Okay. So if this got passed and you said you're not using it, okay, you're not going to get your records in place, and they say I'm going to go transfer it and sell it, you're going to say I don't care about the selling but, yes, you're allowed to transfer it?
John Curran: Absolutely. This is orthogonal with respect to that.
Marla Azinger: Okay.
John Curran: This policy basically states that we have to contact a party, and if the difference ‑‑ the real significant difference is if they're not responsive, then we are put on a path where DNS will be revoked. Okay? That's not a discretionary item in this policy.
Marla Azinger: That's not explicitly written anywhere. That's one of those little details that's kind of a sideliner, so I wanted to make sure I knew how that would play out. I'll step aside.
Owen DeLong: Center back mic.
Chris Tacit: Hi. My name's Chris Tacit, and I'm counsel operating in Canada. I'm just going to focus on a narrow legal issue, and that is the deletion of the word "materially." To me what that means is that there is no longer any discretion not to enforce any breach of the policy. Whereas before it was only once that were deemed to be material. Is that the way that staff is interpreting that?
John Curran: Yes, out of compliance is now out of compliance. I do not get a materiality consideration in judging it.
Chris Tacit: What do you think that will do the workload?
Owen DeLong: Actually, if I can interject, you do actually, it's just later in the sentence where the degree to which somebody ‑‑ Sections 12‑4A and B allow ARIN discretion over the degree to which somebody is allowed to be out of compliance.
John Curran: I'm going to take exception. I want to be very clear. It means we have to look and then determine whether the out of compliance is an issue or not. But they would be found out of compliance because the absence of materiality.
Owen DeLong: Yes.
Chris Tacit: Let me clarify that. So then my understanding is either under the old wording or the new wording, if a noncompliance comes to your attention, you have to look at it. The difference becomes whether you need to act, not whether you need to acknowledge it and inquire into it. With the old wording, if you determined that there is a breach, you would only act if you determined, according to whatever criteria, that it is or isn't material. And this isn't strange language. This kind of language appears in all sorts of contracts in breach sections and so on. So now to me this means that no matter what happens, this process will be kicked off, period, as soon as there's any breach. And I just want to clarify that that's my understanding.
John Curran: You're correct. What it means is in any failure to comply, we have to exercise all in the following bullets in 4. We would then need to be based on reasonable judgment but we with would need to say we did that in every case. That's another aspect.
Chris Tacit: Thank you.
Owen DeLong: If I remember correctly, the word "materially" was stricken at the request of ARIN's general counsel as part of this update. So if Steve is in the house and would care to comment on that, I'd welcome his comment. Back right microphone.
Marc Lindsey: Yes. My name is Marc Lindsey. I'm outside counsel to some of the end users in this space, and I want to echo the comment that was just made, is that this removal of material is significant. It takes discretion out of the action to determine the nature of the noncompliance first. So I agree with that point it is now requiring ARIN to act. Not only requiring ARIN to act, it's requiring reassignment of revocation where it used to say request in a process started underway. So this does seem to be forcing ARIN to take certain actions before it had discretion to do so. And, as a lawyer, my first question always is: Is there a problem that has to be solved here? And I didn't hear anyone come up and say the existing policy and ARIN's way of enforcing it is problematic. If it's not problematic, then why struggle making these changes, which are significant.
John Curran: Thank you. I'm going to actually respond to Owen's question. I don't know if Steve's here, but I can ‑‑
Owen DeLong: He is.
John Curran: So the original comments made by counsel, okay, noted that if we're going to do enforcement, then the act of doing enforcement and the term "materiality" will allow someone to argue whether they think it's material or not and produces a dispute. Now, you remove materiality, but we're in a no‑win situation. If it's in there, then ARIN can exercise judgment and not act, but when we do, it raises a dispute potential with someone who we've acted against and revoked resources. So it's not that he said it should be struck. He's just pointing out that it's an inevitable conflict with anyone who litigates against us. Is that correct, Steve?
Steve Ryan: John, you've been taking law courses on the Internet at night, and you're doing fine.
Marc Lindsey: Can I follow‑up? It goes to my point materiality does make its way in many contracts. It is a source of potential dispute, but the reality is there needs to be some threshold of seriousness before this sort of action is taken. That's why lawyers use discretion. It's typically objective based on the circumstances, not subjective. So ARIN's judgment would be tested against an objective set of facts, which is a good thing, because anytime you have discretion means to be discretion balanced, both pros and cons.
Owen DeLong: That is, I believe, why we tried to preserve the option of ARIN's discretion in 12‑4A and 12‑4B while removing the word "materially" from 12‑4 and the existing policy, it was our attempt at navigating Mr. Ryan's request and apparently we have some work still to do in that area.
Steve Ryan: Owen, you have to stop saying it's at my request.
Owen DeLong: My apologies. Our attempt to address his comments. Mr. Leibrand.
Scott Leibrand: Scott Leibrand, ARIN Advisory Council, Limelight. I have a question. So the current text requires revocation of DNS services after 60 days unless ARIN indicates that they're working in good faith to restart compliance. If that were struck and all that was left was after 30 days ARIN may revoke DNS, question for staff: Would you?
John Curran: In cases of significant noncompliance, sure, we would. But in general when we contact someone and they're responsive at all, we don't have a problem. It's only in the case where ‑‑ it's only in the case when we contact someone and there's no response does the community want us to automatically remove DNS because we cannot contact them.
Scott Leibrand: I think Kevin wants to talk to that point.
Kevin Blumberg: Just later.
Scott Leibrand: I think you answered the other question, but maybe the distinction is how is that different from current policy, under current policy you don't revoke RDNS at all until such time as revocation. And there's been a lot of concern, especially as we get into v6 world where there's nobody coming back for more space, so there's not a whole lot of reason to even look at delegations from a LRS perspective, that ARIN has no way to incentivize people to do this. My question is, if we don't give you this authority, then you're not going to do much different from today. If we do give you the authority, is that a step forward or is it going to turn out that it's easier for ARIN to just not exercise that authority in most cases to avoid getting sued, and it doesn't gets used and it's a no opt without fee, you must do it?
John Curran: To answer that, I want to be clear. We need to understand what problem the community wants to solve. There are three distinct problems you've talked about. One of them is an organization like under v6 that doesn't put reassignment information in. That's a circumstance. That's a directory updating issue. Number Resource fraud is often when we have a party who has requested information or has somehow asserted there's someone else and attempted to change a record to reflect them even though they're not the proper holder. So my question is: Are you asking in general would we want to always do the same response for all three of those cases? The answer is no; we'd love guidance as to what you want us to do, because they are different circumstances.
Scott Leibrand: The question I'm more concerned about, resource fraud I think you have adequate tools to deal with. My concern is somebody who is lazy and never updates their SWIP information ever on a v6 allocation, you see that they're out of compliance, completely out of compliance with that portion and you want to get them back into compliance. If we give you the authority to do ‑‑ revoking our DNS, will you consider that a useful tool and use it than somebody whose only offense is they have never done a SWIP?
John Curran: If we have clear guidance, we'll absolutely follow that. But I'd recommend if what you're looking for is absence of redelegation information, you associate this with that part of NRPM and not Section 12. You have a section in NRPM that specific says you have to put in redelegation information. It's a directory update question. You need to simply state in there that problem, otherwise that solution will be used for cases where we just aren't getting a response at all. And that's a lot of existing address blocks. So if what you're worried about is the v6‑case, for an active contact, that's probably different than what's this policy. Does that make sense?
Owen DeLong: Mr. Wilson.
Paul Wilson: Paul Wilson from APNIC. I just thought I'd mention out of interest we deal with the same set of problems at APNIC in a different way. We primarily, I suppose, deal with this through our membership and non‑member agreements which require compliance with policies. That's a general case, a general cause. As to the question of material or not, I don't think it's ever come up. But compliance with policies is required. And whether there's any ambiguity is actually a question of what's in the policies that are being referred to. The fact that people have to comply with them. But that's where it is for us. And under the agreement, we can terminate services and services include everything we're doing including DNS. And there are appeal progresses and all the normal contractual things that go on. So we don't have specific policies to deal with that, this issue in the same way that you are. As for what we have to do, we do terminate services with reasonable regularity. The breach in most cases is most failure to pay fees.
Obviously much more common issue. But in any case we're notified that there's a compliance problem in terms of policies, then we take ‑‑ as you said, John, we take action that's in proportion with the offense in particular, and I think if we took unilateral and consider action on a relatively small issue, we could find ourselves in trouble. We have to be careful to give people warnings and notice and all that stuff, and I'm not aware that we've had any case at all of revoking the services on ‑‑ of having to revoke services on this kind of compliance issue and found ourselves underchallenged for doing so. It's a different environment, though, that we work in. So I'm not suggesting it would be done with valid concerns here. Thanks.
Owen DeLong: Rob.
Rob Seastrom: Is this one on? Rob Seastrom. Time Warner Cable. I'm on the ARIN Advisory Council. We've been sort of dancing around the fact that there's already a Section 12 compliance review framework, and I think it would be interesting for context in this discussion to get a couple of comments from staff about how often that happens now and the scope of it. And I'm sorry if I'm stealing from Leslie's presentation a couple of days from now, but if we could get a little bit about that to put this in proper context, I would appreciate it.
John Curran: Leslie, could you summarize resource reviews, how many?
Leslie Nobile: So we have looked at this. We haven't used Section 12 quite often, honestly. We thought of three to four recent requests where we did use NRPM 12. I can honestly tell you the only time we have revoked space is fraud or for nonpayment of registration fees.
John Curran: The Section 12 NRPM resource review is not frequent, as in dozens, one or two dozen per year I think, we might do, if that. Most of the activity that we're doing is, as Paul Wilson said, if someone doesn't pay, that leads down a different track of resource review. But the only time that we trigger it is unusual requests, people who have requests that don't match practices or have unusual circumstances or when we have a report that's coming from the community that says a block has been hijacked of some nature. So it's not very common at all. We have a lot of discretion in exercising 12. We use it to clean up the cases we find are egregious. The mandatory aspects of these policy would mean in many cases, if you reported a block that was nonresponding, it would lead down to an NRPM Section 12 action pretty much every time.
Owen DeLong: I believe Mike Joseph and then Kevin.
Mike Joseph: Mike Joseph, Google. I oppose this policy, particularly because as both Marla has previously pointed out and I think as John just alluded to, although Section 12 edits may not be happening that often, the fact is Section 3 already deals with this. And, in fact, Section 12 allows an audit to be conducted for any violation of policy, including Section 3. Moreover, the RSA mandates that all signatories are obligated to comply with policy. So I believe it's very clear that ARIN has the tools necessary to enforce policy today. If we don't believe ARIN is enforcing policy effectively, I think the right direction is to give the Board instruction from the membership that we want ARIN to conduct themselves in one way or another.
However, trying to put mandatory specific actions, particularly specific technical actions for ARIN to do I believe is damaging to the community. Aside from the fact that it opens ARIN to liability, it increases the workload, the workload dramatically, and that means more audits. ARIN is not hiring these extra people to implement this policy for nothing. Those people are going to be involved in contacting people and auditing them regularly.
And I think ARIN staff has exercised discretion quite effectively over the years, and maybe people disagree, but I think overall taking that ability away from ARIN staff means essentially a much more rigid and much less flexible policy framework. And I don't think it actually is going to achieve what people hope it's going to achieve. As John just told us, if a complaint comes in, it's going to mandate a Section 12 audit. That doesn't necessarily mean that the most egregious parties are going to be the ones subject to those audits, it means the people who ARIN happens to notice for a minor section violation of Section 3 are going to be audited. And I think people should really consider that very thoroughly if they believe that what they want is more effective enforcement versus simple procedure‑based enforcement. So, again, I oppose this policy.
Kevin Blumberg: I'm going to bring up an elephant in this room and get people's thoughts on it. The first thing is whenever I see three lawyers come up to the mic and start talking about contractional things, I get worried for any organization I belong to. But here's the question: Are we looking at this policy because as a community we need to do a better job of self‑regulating and if we don't do the job someone else will do the job for us. Is that why the policy exists? If that's the case, are we looking at the policy from the wrong aspect, in that should we be looking at this policy as a self‑regulating body, we need to do a far better job of managing the Whois data and its validity and we need to deal with it from a contractual point of view, from a policy point of view, across the Board we need to have more accurate data. Is that what we want? Because, quite frankly, from my organization, it's more work. But if as a community we need to do this, then what do we do? Maybe if we don't do it, somebody's going to force us to do it.
Owen DeLong: Marla, then back right mic.
Marla Azinger: If he's looking for that to be answered, I'm not going to answer that one.
Marc Moreau: Marc Moreau with the Royal Canadian Mounted Police. I think you summed it up quite well. From a law enforcement perspective, that's exactly what we're looking for. We're hoping that people in the community seize the opportunity to work and to have that self‑regulation, because, if not, if all of the different governments then get involved, it could get uglier. But everything that you've said is bang on.
Owen DeLong: Marla.
Marla Azinger: Are we done with his question?
Owen DeLong: Michael, are you going to address his question?
Michael Sinatra: Sort of tangentially. Why is reassignment data important in your question? Why is it important we have correct reassignment data when we have a responsible party that already exists in Whois? That's the question I'm turning back. And I'm also asking law enforcement that question as well. If you can get what you want from a responsible party in Whois, why do you care about reassignment data?
Marla Azinger: Speed.
Michael Sinatra: I think there's other reasons, but that's the question.
Owen DeLong: Okay. Marla, let's just move on and ‑‑
Marla Azinger: No problem. So if this was passed, you have the potential of having somebody try to get notice to you and for whatever reason you didn't get any response. So ARIN staff decides, okay, we're going to go pull it. And they go pull it. And let's say not even a direct to user is who went ‑‑ it's someone downstream of them that actually has customers and services that rely on DNS actually operating off of the DNS records that their upstream had.
Are you ‑‑ or ARIN staff, are you going to look to support a 24/7 call number so if someone basically, be it their downstream or the upstream, goes I don't know why the right person didn't get notified, I don't know why someone didn't pass the email along, and now services went down, is there going to be a 24/7 call number where they can call and go, look, we don't know why, we're sorry, we heard you, could you please put that back up? So would you be willing to have like a 24/7 number?
John Curran: At this time that hasn't been considered in the staff evaluation. But if you think that needs to be added, then we will discuss it internally. We are actually ‑‑ a number of us are online continuously. So it's not a problem. Minus small caffeinated moments. But it's understood that could be an issue and we'll have to add that in staff consideration.
Marla Azinger: I would prefer it be added because if you went to this change, it would make it kind of really more ‑‑ it might become an issue. Right now there's discretion. So I don't think it really ‑‑ it's not required that they're hunting down stuff. I don't think it's as likely, but if you changed this policy, it would probably become a circumstance every once in a while.
Owen DeLong: Heather and Mr. Flaim.
Heather Schiller: Heather Schiller, Verizon. So, yes, we have in multiple places including the RSA and NRPM requirements that address holders comply with providing different types of information. So their contact information should be valid and their reassignment information should be valid. The mantra from the feedback that we get from ARIN has been that until they're mandated to go and verify that information and make sure that it's accurate, that they're only going to respond in turn to requests that they receive or notifications that there's some fraud going on or something like that.
But unless they're told by the community to actively seek this out and address these issues, they're not going to proactively do it. They're going to do it reactively. So with Whois, there was a policy that went through that said requesting ‑‑ that mandated that ARIN go through all the Whois records and mark which ones were valid and which ones were invalid and attempt to contact them. And they had so many days and those records are marked as invalid.
And to Mike Sinatra's point about why does reassignment information need to be valid when you have a responsible party upstream that's holding the direct allocation, that's not always the case. Go look at those POC records. There are POC records that are 30, 60, 180, a year old that haven't been validated that are still in the ‑‑ in Whois. And under that policy one of the original requests was that ARIN pull out that POC data if it's invalid after a certain amount of time. People said, no, we'd rather very invalid POC data than none at all.
With this, it's taking that enforcement to another step. I think the question is what is the value of this to the community? What is the value of having accurate ‑‑ which is what Kevin was asking, having accurate information in the database? Is it valuable enough to have it to try to have some enforcement action? We're not saying as soon as you notice that there's data that's invalid to revoke their DNS, they have three months. They might have already had a year to get their POC records in order. I don't see this as being ‑‑ if this causes you an emergency ‑‑ my only point about – what Marla also said about this could affect folks, it could create an emergency, would be don't do it on a Friday; do it on Tuesday so you have a few days to get your crap in order.
But other than that, they're giving ‑‑ the policy is giving everyone time to do this 30 days, 60 days, 90 days, plus whatever time to get your POC records in order. I can't see ‑‑ and really the change between it being mandating that ARIN do it versus doing it on their discretion, I think mandating that they do it is fine. I don't have a problem with that.
Owen DeLong: Mr. Flaim.
Bobby Flaim: Hi. Bobby Flaim, FBI. I'd like to echo with my colleague what Mark just said and what Heather said also. The big problem we have is enforcement, and to go to Mike Sinatra, what he was talking about, why is reassignment important, because when law enforcement is looking at these records, we need to know who to serve our legal process to, subpoena or court order or whatever. When we're looking at this information, we need for it to be accurate. Like Marla said, we need the speed because digital evidence evaporates so quickly. That's why it's so key to us. How we get there, we'll leave that up to you, the community. You're the techies, you're the ones that operate the business, we'll leave it up to your discretion, the self‑regulation talked about before.
But it is very, very necessary, the big problem we're having in law enforcement with the speed of technology is the lack of attribution, with v6 considering the blocks are going to be so large and also carrier grade NATs. That's another huge issue for us. It's an emergering. It already exists in the mobile community, and now we're worried about the wire line when they do the transition from IPv4 to IPv6. So that's our major concern and that's why specifically the reassignment and having those records correct, that's why it's so important for us. We've always said it, but we're hoping through all of this you can come up with some self‑regulatory method in which you can do it, because otherwise there will be other things that people are going to consider.
Owen DeLong: I'm being prodded by the chair to again request people state their name, their affiliation and whether they support or oppose the policy up front. Mr. Flaim, can I assume from your comments that you support the proposal as written?
Bobby Flaim: Yes, I would support it unless there's some other mechanism that comes. But for right now, since that's what we have in front of us, I would support it.
Owen DeLong: Thank you. David Farmer.
David Farmer: David Farmer, University of Minnesota, ARIN AC. Right now I think I oppose the policy as written. I would like to request the government folks and law enforcement to create a problem statement for us, because I believe this is a problem, and I believe it's a problem as a community we have to solve. However, I don't think this is the solution yet, and I would like the help from law enforcement in defining the problem so that we can work on this problem. This is an important problem. In the long run, if we don't solve it, it will be solved for us; I truly believe that.
But we need to define the right solution for the community and for law enforcement and for greater society. And I don't think this one's it yet.
Owen DeLong: Back right microphone.
Terri Stumme: Terri Stumme, the Drug Enforcement Administration. And I support this policy because it's a mechanism that will allow us to get to where we need to be quickly. I don't object to perhaps this isn't the right mechanism. Talking to you folks, you folks are the pros in this area. We need all the help we can get to quickly identify the criminals that are out there. The Internet is not getting any smaller. And it's only going to be more of a challenge to us. So whatever suggestions you have that can help us to get to where we need to be quickly, we're welcome and open to receive. Thanks.
Owen DeLong: Scott. Marty?
Martin Hannigan: Martin Hannigan from Akamai Technologies. I'll speak as an individual. I hope we never use Whois as a mechanism to provide people ‑‑
Tim Denton: Do you support or oppose it?
Martin Hannigan: I oppose it. And I hope we never provide or are responsible to provide that level of data that someone has an expectation that they're going to kick a door down and have a valid address. I think the legal process works well now because going to some higher‑level POC requires, one, legal process subpoenas and, two, a vetting of the data that's being handed back so that they have reliable data. And I think that we've gone hugely off topic in this discussion, and this is really Whois debate and I think we probably should have this in some other ‑‑ related to some other policy. And it's definitely not related to this one. Thank you.
Owen DeLong: Scott.
Scott Leibrand: Scott Leibrand, Limelight, ARIN AC. I've heard a lot of objections that would be addressed striking the 60‑day must sentence and leaving it optional. I'd like to get feedback from the community. My personal opinion is I would support this if it were optional for ARIN to pull DNS when they think it's appropriate. I am undecided as to whether I support it as written. I'd like feedback from the people who oppose it as written to know if any of those would support it if it were optional to do the RDNS poll anytime after 30 days.
Owen DeLong: Bobby.
Bobby Flaim: I want to assure everyone that what we're trying to do is serve legal process and make sure we comply with current and existing laws. I can even tell you with IPv4, we have that problem. Because sometimes with three assignments, we'll go to an ISP, serve a subpoena, and they're like, well, we don't have any information for you; it's been reassigned. And then we start going down the line sometimes two, three, four, five different ISPs because of the assignment, and therefore we've lost the momentum, lost the speed, lost the evidence and therefore our case is closed because of such as instance.
So just to assure everyone, this is a public safety issue. Kidnapping, child exploitation, fill in the blank. This is a public safety issue, like Mr. Farmer was talking about, and what we're only seeking to try to do is maintain current capabilities and to serve legal process and comply with the law.
Owen DeLong: Thank you.
John Curran: We are now passed time. People need to understand we're going to close the mics shortly. You should get up and line up to the mics or put in your remote comments if you're going to do so because this session will wrap up in some short period. Marla.
Marla Azinger: Marla Azinger. I work for Frontier Communications. Right now I'm not in support of it, the optional question. If staff was going to make it optional and they decided when or when not to pull DNS and let's say the reason being is legal or law, some enforcement entity contacted ARIN and said their stuff is not there, it's never there and we need you to take this stick and beat them with it, well, when you use the word "optional," I question, Steve, if you're paying attention, do you enter an unfair practice situation where you're treating an entity unfairly compared to another one because the week prior you had this case and you said, okay, you understand the situation, they said, I'm bad, we'll fix it, so you didn't pull DNS. But when the law comes around and they say ‑‑ which, rightfully, I think they should be able to ‑‑ but when they come around and say that and ARIN says, okay, fine, we're going to go pull DNS, are you entering an icky lawsuit, unfair practice kind of scenario?
Steve Ryan: We have contracts with 3500 ISPs in North America and in the Caribbean. We can always enforce those contract rights. Those contract rights relate to the policies. They relate to policies in. So the policies are part of the contract, if you will, in terms of the interpretation of that.
We have the discretion, in every policy, to make decisions as a staff and as counsel and as an organization what enforcement activities we'll take on a contract if a policy doesn't have a descriptive enforcement mechanism in it, or if that provision of the contract doesn't say if this provision of the contract is violated, there's a dispute mechanism in there, there's arbitration in our later contracts, there's all of those things. So from my standpoint, whether you pass this policy or not, in a generalized sense that always is our right as an entity dealing with people who violate our policies.
Now, there are people who intentionally violate our policies. There are people who go out of their way to send us a legally threatening communication when they're violating our policies. We address those people in a certain way. What you're dealing with here is deciding when people don't reply and are out of communication, how do you judge that being out of communication and the unwillingness to comply, because if they're in communication with us, we then can judge which side of that ledger they're falling on in terms of the activity that we do. So does that help you?
Marla Azinger: I'm hearing you say the word "optional" does not concern you. Is that accurate?
Steve Ryan: I'm not particularly worried about it in that aspect. No. I don't think ‑‑ I'm not an Assistant US Attorney anymore where somebody could say, well, you brought this one and you didn't bring that one and you abused your discretion by not bringing the second one or by bringing the first one. I don't think ARIN has that problem. Somebody may argue that we have a problem with regard to inconsistency, and they're welcome to the argument. Is that all right, John?
John Curran: Yeah. The one thing I will add, just to be clear, is that we also need balance to the rest of the organization. So what that means is if you make something like turning off DNS service a potential, an optional item that the staff would consider, the challenge you have is that that bears risk to the organization. And that risk really doesn't go away unless we have an objective standard as to when we're turning it off, because someone's going to be harmed when we turn off DNS. So saying: Staff, turn off DNS when you think it's appropriate. I'm a very conservative soul. I don't want to hurt anyone on the Internet. If you actually expect to see a large number of reverse DNS services turned off, the closer you get to an objective standard, the more likely you are to get to that result: Does that help?
Marla Azinger: Yeah. The word "optional" made me think more. But in the end I'm not really sure what would make me roll over to vote in favor of it, honestly, because there's still so many other consequences going on. So I guess right now I'm still opposed to it.
Owen DeLong: Okay. Mr. Joseph.
Mike Joseph: I still oppose this policy, and I'll sum it up succinctly. ARIN still has the ability to enforce this. As Steve mentioned, ARIN has the ability to enforce Section 3 through the RSA and other mechanisms, if we want ARIN to do it during the general Members Meeting, stand up and tell the Board you want ARIN to do this. We shouldn't be codifying in NRPM specific directions for ARIN to conduct more audits and tying their hands and how they conduct those audits. Thank you.
John Curran: Okay. I'm closing the microphones. If you're approaching the mics, you have ten seconds. Remote participants, same. Microphones are closing. Microphones are closed. Thank you very much.
John Curran: I guess, Owen, I'll ask: Do you want a show of support for this policy as written? Or are you going to go back and rework it?
Owen DeLong: I think we should ask the question, and I'd also appreciate it if we could ask the question as Scott proposed.
John Curran: Okay. I'll turn it over to you. Our tabulation system will get set up. The high‑tech tabulation system.
Tim Denton: Have we got our counters? All right. In the matter of 2007‑11 ‑‑ 2011‑7, those in favor of the proposition, would they please raise their hands high and keep them up there for a bit until the counters signify to me. Okay. Those against the proposition as written.
John Curran: Gotta give them a moment to count.
Tim Denton: Okay. As expected, the Compliance Requirement, 2011‑7, total number of people ‑‑ I need to get my tongue coordinated with my brain. Total number of people in the meeting room and remote was 115. In favor were 11 and against were 31. So given your advice.
John Curran: Now, Owen, I believe you wanted a second poll. If I can understand that poll, that would be in favor of 2011‑7 with DNS revocation or reverse DNS suspension optional. Does everyone understand that would be the same text, only reverse DNS suspension would be optional, it would be discretion of staff? Are there questions on that? I see a question. Jason.
Jason Schiller: Jason Schiller, Google. I just want to make sure I understand the point, and that is not that we support future work on this and future work should make it optional, this is actually pass the policy as written with that one change. Is that correct?
John Curran: This is to show support to the people working on the policy. This does not pass or adopt policies in any way. This is simply an indicator of support for a policy proposal that has those characteristics that would go back to the shepherds to try to shape the process.
Tim Denton: In other words, by this vote you're sending them a further piece of advice.
Jason Schiller: A further piece of advice for continued work?
John Curran: A further piece of advice to work on 2011‑7 with an optional DNS suspension.
Jason Schiller: Thank you. That clarifies it.
Tim Denton: Marty, you're next.
Martin Hannigan: Hi, I'm Martin Hannigan from Akamai Technologies, and I actually oppose this line of questioning and I object. I think that this is better served on the Mailing List. My concern is that this actually is something that is put into play rapidly and without additional vetting. I think this is a very complicated discussion and that we should take it slow and take our time to try and accomplish these improvements. Thank you.
Tim Denton: Your point is taken. And I say a negative vote on this proposition would be to the effect of what you're talking about. Scott Leibrand.
Scott Leibrand: As I intended my question to the room, which I think is being appropriated here, that it would be just simply striking that sentence that says after 60 days DNS must be revoked and otherwise giving the Advisory Council direction that you favor the rest of the proposal and you would like to see it ‑‑ I would envision this something that would go out to discussion on the list and then last call before another meeting.
So the question to my mind is do you support it with that change moving forward through the process in the interval between now and the next meeting. And then I presume you would be doing a subsequent question of continued work on this like we normally do. But I think that's a separate issue.
So I want to understand as well, if the question as stated is to just strike that one sentence and otherwise give the AC direction to move it forward, that's what I understood the question to be. But I want to make sure we share that understanding.
John Curran: So I'm going to note at this point that we are over time for discussion of this. And we have not discussed what you just proposed. That was not something that people had a chance to go to the microphones and talk specifically in favor and opposition of.
As such, it would be suggested that a poll on this where people haven't had time to line up in favor and opposition and speak is not in order. Now, I've indicated that to this group before when that's happened and been overruled. So I'm not going to put it to the Chair, unless we're going to continue the session to allow people to talk about what Scott just did; I suggest we not conduct a poll in support because I don't think people have had an opportunity to discuss what you just suggested.
Tim Denton: I agree. I don't think a second vote at this stage would be appropriate. I think we'll just leave it as such.
John Curran: Thank you.
Cathy Aronson: Okay. And is it like right and left?
John Curran: Right for right and left for left.
Cathy Aronson: So there's been two IETFs since we last met, which makes this a little longer than normal. And I learned a lot of translation issues that several of them are in the slides, and I learned that explodes the fresh milk actually means bursting with fresh milk. It took me quite some time to figure that one out. And I think I got the ARIN number wrong. Oh, well. Sorry. Anyway, last time we were in Vancouver the Gong Liberation Front stole the gong and it went and visited the Dhali Lama. Those of you who can remember that far back will remember the gong, and we'll all take a moment. Anyway. This is the disclaimer slide. It's really fun to do this with Marla on the stage, because I'm kind of Marla right now.
So this is my take on it. So if you were at IETF and you think I missed something that's important or you don't agree with me, feel free. I just amuse myself and I make slides with quotes and translations and stuff. Highlights ‑‑ it's interesting to me ‑‑ I'll talk more about these things later ‑‑ but there's interesting issues with v6, like DHCPv6, like no one intended DHCP to be an environment where some things ran it and some things didn't. So like in v6 it does things maybe it shouldn't do, and people are working on it. And the address space is really big and there are attacks that can happen because of that. There's a lot of really interesting things going on. So I have more comments about those as I go along. The shared transition space happened. There's a block. It got approved. Yea. So everybody that wanted that, that was a collaboration between our community and the IETF.
Here's some random quotes taken completely out of context. So you can browse them at your leisure. What else? So I'm sure we're going to be talking about that probably next, but there's this World IPv6 Launch thing where instead of day they turn it on and they leave it on. There was a really good panel that the ISOC put on at IETF about it, which was super cool, and there was a panel of ‑‑ none of these folks were on that panel. So this will be a different panel. But it was really interesting and it's going to be exciting to see what happens. Yeah, a panel of ISPs. I don't know why.
So another translation issue that we came across ‑‑ and there's so many lawyers in the room, it's just excellent ‑‑ "Lawyer With Vinaigrette." I just wanted to point that out there.
Cathy Aronson: I took a picture of this and I posted it on my Facebook page, and my girlfriend said: But what about the plate of "But Cher's Shop"? And I didn't even notice that because I was blinded by the "Lawyer With Vinaigrette." Anyway. This is really apropos to some of the IETF working groups right now. So apparently the word for "avocado" and the word for "lawyer" are the same in French. Geoff gave a really good talk here today, but he also gave a really great talk in Taipei, which was the first of the two IETFs since we last spoke about stability in the routing system.
There were several really great reports about the quake. And there's a continuing work being done on how much BGPSEC costs like to authenticate and make the routing table converge. So there's some interesting presentations about that. Let's see. They're doing some work in Japan. There was a presentation about IPSEC ‑‑ I'm sorry, DNSSEC and the difference between getting critical, using CGN, and whether we should use CGN. And we heard today that it probably won't scale.
I think the most interesting talk of the session that I went to, one of the more interesting talks, was distributing the RPKI with BitTorrent. Everybody was shocked because it's BitTorrent and you only really do illegal things with BitTorrent. And there were people that thought it might be brilliant but yet their company would never let them use BitTorrent, so they were trying to figure out ‑‑ but, anyway, Rob put together a really ‑‑ he's doing quite a bit of work on it, and it's actually kind of cool. So let's see. And the IPv6 maintenance working group, there's a bunch of different projects going on.
I think that energy‑aware devices stuff is really something that's going to be more and more prevalent, like things need to use just a tiny bit of battery they don't need to be chatty all the time, they just need to wake up when they need to, do what they need to do, and then go back to sleep. So there's a whole lot of work with that. Because everything we've designed so far is designed to just be: I'm here, I'm here, I'm here, I'm here. And there's so many devices coming along you don't really want them to say they're here all the time; you just want them to do it when they need to do it and then their battery to last for ten years.
Let's see. There was another draft about IPv6 over MS/TP. Which is not my favorite. Let's see. So what happens when you're doing IPv6, what address do you choose? How do you know whether to use your v4 address or v6 address or maybe your v6 doesn't have global connectivity or maybe your v4 has global connectivity. There's a lot of work being done now about how do you decide. And even some more work being done on, okay, so what happens when you're using 6‑to‑4 or 6rd or something and then you get a real v6 connection and then what do you do, how do you choose.
There's a really controversial presentation about packet staining, like putting information into the packet header of whether this is like a good packet or a bad packet. And that wasn't super popular for a lot of reasons. Let's see. The technical plenary. Yeah, there's a whole lot of work, a whole lot of presentations about this concept of devices, you know, just doing a little bit, like they said it's garrulity and fluff, so they're too talkative and they have too much stuff stuck to them, like lint. So energy‑aware devices, devices that need to be, like I said, up for a long time but only need to do a little thing and you don't really want to have to go fix them or change their battery. There's a little bit ‑‑ only a little bit of code. Anyway, it's a pretty ‑‑ there's a lot of work being done with that right now.
And the transport area, there's a bunch of RFCs that have happened. They're listed there, different port uses, experimental options. So if you're interested in that stuff, you can take a look at those. I have links at the end. Now, Softwire. In Taipei Softwire was the usual ‑‑ I don't know if you followed it at all, but it's basically everything over everything, so v4 over v6 networks and v6 over v4 networks. And whether you translate or you encapsulate or ‑‑ and there's just competing proposals where one's just a smidge different than the other one, but they don't want to have the same proposal. So it's kind of crazy a little bit. And in Paris there was a huge discussion about trying to focus the group on a solution.
So I like the analogy at the bottom. This guy from Canada said they used to have three churches and then they decided to consolidate and so now they have four. It's kind of like Softwire. It pretty much fits. So in Paris they were talking about do we do encapsulation or translation? And they were trying to get consensus around one and there simply wasn't any consensus. So I'm not exactly sure how that's going to move forward or how it's ever going to coalesce over a solution.
And this, I don't know if you guys can see this, but this is in the slides, and this is just brilliant. So it's like this translation guide that they put up in Softwire, where what the British say, what the British think they said. Anyway, if you get a chance to look at it, it's totally a riot. I don't know how well it's projecting, but it's super ‑‑ can you read it?
John Curran: It's not bad. It's good.
Cathy Aronson: So I hear what you say. I agree not to discuss it further. He accepts my point of view. It's really super funny. It took me a while to get it, but if you get a chance you can use it in your slides, too. It's really good, it's just like what happens here, huh?
Cathy Aronson: We all agree.
Geoff Huston: Very interesting.
John Curran: I find it quite good.
Cathy Aronson: And then v6 ops. There's a lot of work being done on customer edge routers, which will bring me to Homenet in a few minutes, my favorite working group. Like I said, there's a whole bunch of problems in DHCP, and what do you do with the host you're not really ready to do DHCP with yet, how do you shut them up. And there's problems with neighbor discovery. And then we talked about this ‑‑ I think I talked about this last time. Igor has a draft about so the address space is huge and maybe you're using this little bit of it, but somebody could port scan all of and it do this huge denial of service attack on you. It's really great to have these big address blocks, but all of a sudden you have these really big address blocks. So that's been split into two documents: One is the problem statement and one are the possible ways you could shut it up or prevent it from happening.
Let's see. There was a great presentation from the guys at Wide about their v6‑only network in trying to do v4 over v6 only, which is one of the varying Softwire ideas and some of the problems that they had, that 20 percent of their users were IPv6 only which is pretty cool for their trial. Let's see, lots of v6. There was an update from China Telecom about their IPv6 deployment. And then Mark Townsley, who I don't think is here this time, he's got a draft out called v6 Sunsetting, and basically he's talking about what I said earlier where say you're doing 6rd or 6‑to‑4 or some tunnelling thing and all of a sudden you have a v6 connection, how do you decide which one to use. And he's trying to focus people around a standard CPE device choosing algorithms so that you know, oh, look, I have real v6; I don't need to do that tunnel thing anymore. So that's a pretty good read. Let's see. More about Wide. It was two different meetings. So there's just a whole lot of stuff going on.
Let's see. The CGN problem that's being documented is so say you've got ‑‑ you're doing translation behind a CGN and say you have some really misbehaving stuff, in the same block is a bunch of really good guys, but somebody filters you, then what do you do, because they're huge blocks and maybe you have some bad guys and some good guys, but all they see is that address. So then they filter you and so what do you do?
So IPv4 end of life. The really cool thing about some of the discussions that are going on at IETF right now is that they actually talked about us. Super cool. They're saying, well, the registries are starting to focus less on v4 allocation policy which, of course, from Leslie's slides you found that we really aren't, but in theory we should be. And they're starting to come up with like ‑‑ they're talking about an end ‑‑ a v4 end‑game working group. And they're also talking about why is it happening so slow, are the lenders lazy, there's all that stuff going on. The big problem is, of course, that v4 and v6 are incompatible, and when it seemed like a good idea ten years ago, but maybe not so much now.
John Curran: I'm sorry.
Cathy Aronson: It was a really good panel discussion about all the different topics and tunnels and why they're compatible. Are you okay?
John Curran: Yeah, I'm fine. Sorry.
Cathy Aronson: So there's another one of these v6 into v6 translation, they were talking about ‑‑ which made my head hurt. And let's see. There's a lot of discussion going on about where does v6 now fit into the IETF's workspace. Like should everything have v6. And they're saying that it should be mandatory now, because it should be mandatory, and that v4 is going to be phased out and eventually there will be v6‑only standards, which that would be cool, I guess. And then they did, like I said, they mentioned us. The RIRs are setting the example, apparently. Well, you know, it was nice of them to say.
Dynamic Host Configuration. There's a whole lot of discussion going on about, like I said, how the hardware picks its address. And they're talking about doing multi‑homing where the host picks the address based on which way it's going out. But I don't know. I don't have a lot of hope for that. DNSOPs, there was a proposal to put your CIDR prefix into your DNS entry which doesn't change the protocol or anything and I guess some people are already doing it. And then there were these great competing proposals. One said the time to live should be longer and the other one said why the time to live should be shorter. And they were completely orthogonal.
And they both had really good reasons. So I don't know how you would pick whether you would want to make it shorter or longer. So RENUM. So everybody has accepted the fact that in v6 we are really going to have to renumber. I know it seems like maybe we wouldn't, but we will. And people are already having to renumber because their address plans change as they deploy. So there's an enterprise renumbering draft right now. If people get a chance to read it, I'm sure the author would love feedback from people who might actually readdress their networks.
Let's see. One man's rogue is another man's renumbering event. Super cool. So there's a lot of things that we code in our address space. Like addresses, a lot of ‑‑ and how do you deal with that, the things that you have to hard code the address in and maybe we could get rid of that in v6. Let's see. You can't automate ‑‑ what you can't automate is fixing stupidity, which is probably true. Let's see. That's my little summary. Static addresses are an issue. Multicast appears to have a lot of issues. So there's a lot of work going on right now in figuring out how to more effectively renumber in v6.
So Homenet, my favorite working group. So imagine a whole bunch of geeks that have like a closet full of networking gear in their house, because they're geeks, trying to design your grandma's home network. It's super funny. It's like, no, they're really going to want to have three LANs and their own mail gateway and maybe they'll have a public NAT and a private NAT. 99 percent of the networks have a cable modem and a PC. But there's a whole lot of work going on to design like the world's best home network. And it's really super funny. It's kind of crazy. But apparently arbitrarily ‑‑ and they want it to be arbitrarily complex and they want you to be able to walk in and just plug your Linksys in and have it work. Super cool.
Let's see. Operational security. There's a whole movement to use like v6 private like link‑local addresses on your network core, which has all the same problems as using RFC 1918 addresses, like you can't ping from the outside. Anyway. So ISPs aren't super fond of it. But it reduces the attack domain as they call it. But they're hidden because they're private addresses. So there's a draft about that.
There's human‑safe IPv6, which I thought was pretty entertaining, because you take this hash and then you use that with the name to get the address, and it's way more complicated than trying to remember FFF colon whatever. I didn't really see the point of it. Global Routing Operations. So in Taipei I was supposed to go to Behave, it was the last meeting of Behave, but I didn't go to Behave because I presented a draft for someone else at GRO. So I have a couple of quotes from the Global Routing Operations working group. I like the "Randy Bush Internet salmon," was a particular favorite of mine. And "in five years after someone has invented layer 5 VPNs." So, anyway, I ended up there on the stage. Super cool.
There's a lot of work being done in CIDR with BGPSEC and how long it takes to authenticate, and they don't really have right now a baseline, though. So like it's hard to compare the 80,000 routes in 32 seconds to what those 80,000 routes actually take without BGPSEC. So I think there's a bit more work that needs to happen with that. And that would be my questions slide. I believe that this sign means don't drink and drive. But it was in my cab in the back in Taiwan.
John Curran: Any questions for Cathy?
Cathy Aronson: And this is where to find all this stuff.
John Curran: Okay. Thank you, Cathy.
Aaron Hughes: All right. Good afternoon. For those who don't know me, my name is Aaron Hughes, president and CTO of 6connect. This is a panel on IPv6 successes and setbacks. This is a little different for ARIN. The last time we did something like this was about two years ago. And the idea is to get some operational representation in the ARIN community about real world v6 experiences. So I know we do have a joint meeting every October, but I don't see a lot of you guys in NANOG, and I don't see a lot of NANOG attendees at ARIN. So this is to bridge that gap a little bit and give you an opportunity to hear from people who are really using v6. So this is about real‑world v6, where we are today, what are some of the setbacks, how do we get through some of the challenges. And the perspective is from a wide variety of v6 users; that is, service providers both from DSL, from cable. We have an enterprise perspective and some government and educational perspective.
So first I'd like to introduce the panelists. For those who read the agenda or just heard John, John Jason Brzozowski was here representing Comcast, and he apparently had some flight travel issues, so Dan Alexander is here in his place. He's an engineer standing in for John, last‑minute thing, so try and go easy on him. We also have Marla Azinger from Frontier. She's a senior data engineer in address management and planning, and she'll be sharing the decision process Frontier uses to determine what direction to pursue and their three‑prong approach; that is, tactical, long term, and stop gap.
And then we have Casey Deccio from Sandia Network Labs, and Casey will be sharing experience in deploying IPv6 in the enterprise, speaking specifically about native IPv6.
And Michael Sinatra from ESnet. He will explain both organizational and technical obstacles to more widespread development among EDUs and governments, particularly national labs, and how these obstacles might be overcome. So the agenda is pretty straight forward. Brief presentations from each of the panelists, and then some Q&A. And I'm going to lead with a few questions, and then we're going to open it up to audience participation. And with that, I will give the floor to Marla for the Frontier presentation.
Marla Azinger: So my apologies. Some of you are used to my presentations which usually are much better at being put together and pretty and de‑kludged. These are very much a lot of words. I didn't have time to reduce it and make it pretty. So you get it all. So Frontier had ‑‑ I attempted to get v6 started back in 2003, which was somewhat of a success because I was in the engineering group and they listened to me when I said we need to start buying dual stack and be ready. So we at least did that. So between 2003 and 2006, everything that we bought new for the backbone was dual stack. 2008, we started on the v6 management side of the house and the database creation. I know a lot of people use different things. There's IPAM. And I think most people use internally created software to manage their address space.
And that's what Frontier uses is internal home‑grown stuff. So I started on that because other things are going on at Frontier and v6 wasn't going to move forward yet. So what can I do? I worked on the database. 2009, I had to do something to try and get people to listen. And the executive level intro was given. I put together a presentation in order to try and spur some support and you should give a hoot speech.
And we got to 2010. And we're still crawling a lot. So at least we did succeed in the backbone, completely, with getting that dual stack. The Frontier network analysis and v6 deployment was conducted. I laid out technical options that existed because there are a number ‑‑ I really don't think there's a lack of options. There's really almost too many options sometimes when you look at it.
And Frontier, because of the situations and things it needs to look at, I had to use weighted measures such as how much money we had to spend on it, the employee skill level that we have going on, and the availability of employees to actually assist with the v6 integration.
What I didn't count for but I would have had to have the crystal ball really to do it is the focus that Frontier kept getting at the end of 2010 we had our backbone completely dual stack out to you, the edge routers, and it was a big project, it was a lot of equipment we swapped out and basically we were tired. So we took a month off. It only took one month from Frontier to all of a sudden inform us out of the blue that we were purchasing a bunch of Verizon territories and that was now our focus. V6 project we put off for a month so we could get a little rest and get caught up in other things that were being ignored. Got pushed aside again.
So instead we had the factors of 14 states that we were adding of territories and customer base and renumbering all those into, yes, not v6 but v4 address space. Because that's what they were all currently using.
So it was a lot of side distraction. The company has been very much the product and marketing focus. I think some are aware, and if you're not aware, you need to be aware, that that, with any company, pretty much runs the ship.
If the money can be seen in a certain location, that's where the focus goes. So I kept trying to move forward with what we could do.
2011 came around, and I finally had some of the senior executives saying, okay, we probably should start looking at this now. But this is also at the same time that we're fully integrating the Verizon networks we purchased, and modifying a lot.
So I was told make a team, here's some people that should be on the team and go for it. And no this is not your full‑time job, this is a project. So it was handled as a project. And I decided after a couple of meetings that it's not going to go very far, very fast when you don't have a dedicated group. But what I could still at least knock out is the mission statements, the project scope, how we're going to go through it.
Put together really what plans make sense for the company itself and basically use that time instead of just sitting and waiting for the perfect golden moment, because it will not arrive for most of you, that golden moment where they say here's your money, here's your equipment, here's your people, it's not going to happen. You need to filter in what you can when you can.
And my goal, of course, is kind of like an overkill statement, but sometimes if any of you do negotiations you know you kind of have to negotiate heavy on one side to work towards where reality is. So immediate implementation and testing and all that was how I approached it. And that got a little attention doing that.
The whole breadth of the project has to start with the inventory discovery, which can be taxing in some situations. We, fortunately, had the ability with our firmware and back‑end office systems to actually pull all the different equipment, a list of what we have. And then find out what is v6‑capable and which isn't. The only way you're going to be able to find that out is testing it, asking your vendors if you haven't gotten to this point yet you're going to get told, oh, yeah, yeah, it's good, and it most likely is not. And you have work to do. And you have work to do to push them first.
So the project is integrate v6 with v4. It's not to shut off v4. And that's not part of the project for Frontier right now at all. We're not going to predict when that should end. Really that's too far down the road for us. If we can get integration and be able to do one or the other, when needed, that's what we're going for. So 2011, I'm still trying to convince everybody to walk. It's still a crawl.
So getting them to stand up and actually walk forward with v6 is still a task. Part‑time v6 planning and all that, the integration and testing was given a small push, but that was only because every spare minute that I did have or make myself have was because I was seriously beating up vendors and getting equipment in a lab, and I also had to beg, borrow and steal to get a lab even at my own network, because we have all this other stuff going on for the other projects like the integration of the rise in territories and other testing that's being done. So DIA, that is one direct Internet access, is one of the areas we do have success right now, because we are v6 dual stack all the way out to the edge.
We do have customers that can actually do v6 native if they want. We don't currently have anybody other than our beta customer that is up and running on v6. But other ones have the v6 address space from me and they are testing it in their labs and playing around with it. So we're crawling. V6 awareness plan, it's ongoing, something that I have to keep hitting up the internal company‑wide publications on our internal site, informatives and training sites for all that has been nonstop. And it needs to be done, because people, when you have companies that are product and money focused, like they probably should be, the v6 is just a technical aspect to them. So you need to start relating the fact once we run out of v4, if you can't get your customers to use v6, you're not going to be making commission.
So you have to learn how to talk to sales and marketing and the higher regime to really explain this is important, it matters, and you're going to run into a wall eventually if you don't push it further. So the project plan was created with a statement scope. I ended up creating three phases in it in order to break it down bite sized. There's inventory, network planning, including the testing and the implementation. Inventory is always ongoing. If you think you've got it, you're going to find equipment later that you didn't know existed even though it should be somewhere and reported. But there's equipment everywhere, and places you don't even know it exists. So that's been a little fun, too.
The risk assessment, this is also how I've been trying to relay it to everybody in the company. You've got your runout, and that's going to cost money. And then there's a head‑count issue as far as how many people you have to work on the project and their deadline. The risk assessment should include we're not going to get here because of these things that are causing risk to the project itself.
The vulnerabilities are your products, the addressing, the vendors, training, v6 experience. There is a number of vulnerabilities that you'll run into when you make this a project. Tactical deployment testing plan. That was written, and not to my ‑‑ I like to make things perfect, but they don't always get to be that way. So you should have a very detailed testing plan for everything. But if you do not dedicate a team to it and you do not dedicate engineers that are familiar with the network, you're not going to get a detailed testing plan like you should have. And if you don't push your vendors as well, the CPE was a big up front issue, we knew, because we needed to do dual stack. And we're choosing to work with DHCP. And we also have PPP requirements that we're still going to need to service.
So the vendors unfortunately are not leading the way. It's more like a chicken and egg situation. For many years we've been in a situation where if I need a new CPE, I can just go to the vendor and say give me what you got if it does this, this, and this. And the only thing you have to modify is really the actual user experience where you tell them when my customer goes to the website to look into their modem, I want them to be able to see this and select this and that. That's really all you ever had to tell your vendors. Now if you want v6, you basically have to give them very specific technical specs, and there's not a lot of people that are actually familiar or used to writing technical specs per CPE. So you really have to get in there and get dirty.
You end up doing alpha and beta testing for the vendors. You really should be able to say, vendor, give me this, and they already alpha tested it, they already beta tested it and it's good to go, but that's not the case. You're doing alpha and beta, everything. And it's the full‑blown testing situation. So the more people you can get dedicated to the project, the better it's going to be for everybody. I have too many slides. Sorry. What can I skip? Public involvement, because I don't have a lot of people working on this project, and no one is full time 100 percent to it, I decided to throw public involvement kind of out the door from this part.
So we're not attending the v6 summits. We're not going to any of the v6 conferences. Emails, when people send me emails and ask me something or want to discuss something, I choose to spend time on that for public‑type stuff. And not get sidetracked, basically, in all the other stuff ‑‑ I know this is a discussion, I think I heard Geoff Huston mention it this morning, why aren't we saying anything. I don't have time. I don't have time to say anything. That's one of the areas that I just cut, because I just don't have the time. I understand and I have a appreciation for Comcast because they're out there doing that, but I don't have time. We're one of the ones hiding and trying to get it done. So my face is going red, I think. All right. v6 ‑‑ this tells ‑‑ my slides have more than any should be on any presentation. So this looks ugly. I apologize.
I just wanted to draw out basically the deployment strategy we did come up with. We have tactical, we have strategical, which is a long term, and then we have the stop gap. So for our tactical approach it was more what can we do now. Back‑end office systems and the IT area I could do because they actually have their own project managers, so I stole one of their project managers and got them to push all the back‑end office platforms and changes in meetings that we had to do for that. So that's all done. We're actually completely done with all platforms as far as that aspect. But we still need to test them. And we didn't get to test them because of where we are in the lab with the other stuff, which I'll get to real quick.
V6 management is another thing you can do if you don't have dedicated people 100 percent. You can still work on what subnet size, and what comes into play there is your CPE technical specs actually matter as well because you have to tell your modem maker what you want it to do, what you want it to hand out. And then you also need to reference what your router is doing, your upstream BRAS, because if it's doing a /64 and you wanted to do a /128 or something, you have to actually work with Juniper and your CPE maker.
So there are some things that are already set in stone. /64 is something I'm seeing. So that kind of tells you how much address space you have left once you realize you're using everything by /64s for the smallest subnet that's being handed out. There's a lot more with addressing specifics. If anybody is interested, they can read through the slides and ask me questions later if you have any. The tactical approach was also what products can we hit that uses the most address space and then start kind of reclaiming it a little bit if possible. We're the largest rural DSL provider. That's where we focused.
Then I looked for equipment that didn't have all the product services going on in a certain area, because then it's less that I have to test. And then I also looked for what router we had that I knew I could do just an upgrade on software‑wise and not actually have to swap out the equipment. So I basically looked for a tactical approach. The easiest one shot. I'm going to get it done and not have to test absolutely everything out. In order to do that, because I didn't have people, I also stole somebody else's expert Juniper person. It was a different company's person. But if you lean on your vendors pretty hard, they'll actually push forward something for you to utilize. So I had somebody else's engineer in my lab for three days doing upgrades with the small skeleton crew I did have. It got us very far very fast for at least that aspect because I leaned on the vendor.
And don't be afraid to get creative with where you're finding resources, because I definitely suggest doing that if you don't have dedicated people, because it's the only way you're going to move things forward. So that's more equipment details on what we did and the upgrade we did. Testing hiccups. The DSLAM that was, okay, no problem, there shouldn't be any issues, it's not okay. There are problems. And it needs upgrade. Once you can show them the proof, the vendor goes, oh, right, yeah, our bad, that's on our roadmap.
Roadmap is a buzzword I think you should be fearful of. If they say it's on the roadmap, that means it's not done and they're thinking about it and you need to make them give you a date because otherwise you're not going to get it. Stop gap is carrier‑grade NAT. Geoff, you can sleep for a second because I know you don't want to hear this. The carrier‑grade NAT is something we're looking at, we're testing, we've had success with it. There were some issues. Since we're running out of time, I'm not going to go through that, but my slides clearly detail it.
So IP requests are vetted very thoroughly. I have received several requests. I started that a year ago doing it even more when something smelled a little fishy. Now if it's even a little fishy, I dig. And it's been interesting the things I've found that people are trying to pull. Company‑wide education keeps going. That's more NAT, sorry. But that will save address space if we have people using address space in that while they can. And then the long‑term approach is our next‑generation equipment, which we've got a couple of different vendors in the lab, and that's for the BRAS swapouts completely in all the other geographical locations where my E320s are not. Eventually the E320s will get swapped out, too.
Wow. Sorry. Small print. So basically it's make a plan and make it work. If you can, make sure you get dedicated people, not a side project‑event going on, because that makes it really difficult. Make use of your vendors and push them. And there's some examples on here. When you get your microscope out, you can see what I wrote. And what if no one knows v6? Who cares. It doesn't matter. If you grab people who are network‑intelligent and can read, then they can do v6 for your company. Get them going reading and have at it.
Aaron Hughes: Thanks, Marla. All right. We're going to do Sandia. All right, Casey.
Casey Deccio: All right. So I'm going to ‑‑ my name is Casey Deccio. I'm at Sandia National Labs. When my slides come up, I'll talk a little bit about ‑‑ I guess we're ready to go ‑‑ I'll talk about some of the experiences we've had deploying IPv6 in the enterprise at Sandia and some of the challenges we face, some of the things that worked well, and use that experience to hopefully help some of you. But a couple of things that ‑‑ principles that we kept in mind as we've been deploying IPv6. Number one, most enterprises, when they're deploying IPv6, they're typically working on an existing IPv4 architecture. Also, there are certain processes in place for processing your IPv4, whether it's working with an IPAM or whatever, that oftentimes you can't just throw out and start from scratch. So you have to use a lot of existing processes where possible. And some of that even involves political adherencies to old processes.
And also when doing this, you wouldn't expect the IPv6 would be deployed in the entire enterprise. So any type of project plan that would need to go out for deploying IPv6 would need to take that into consideration as you're doing these steps. So I'll talk a little bit about addressing architecture and some of the observations we're seeing. I don't know that we'll have a chance to talk about the last one, but I left it in the slide deck just in case. So in terms of IPv6 addressing, we followed practices that actually ARIN presented a while ago at the last NANOG meeting in terms of the best current operational practices group. And so they follow it similar to what was outlined there in terms of subneting your site prefix and basically what we've come up with is I've given it a /48 prefix. We're using four bits to determine a particular network environment.
Then within that, of course, we're using 64‑bit prefixes, which gives us 12‑bit to come up with a network identifier, which is typically our VLAN, so we can then have same way of mapping our existing v4 subnet space to our VLAN. We're doing that to the v6 and we're using that doing VLAN value. For point‑to‑point subnets, we basically ‑‑ in each environment we're using the last IPv6, quote, network, the /64, we're reserving that for point‑to‑point addressing within that particular environment. So we're just basically assigning point‑to‑point sequentially within that using /126 prefixes. And there's some discussion about whether it's best practice use /64 versus /126, versus /127. We like the simplicity of using /127, but because of certain hardware constraints, routers ended up having to use /126. That's what we ended up doing. And that's actually worked out quite well.
In terms of our host addressing, we basically have two different environments ‑‑ excuse me, paradigms here for host addressing. One is fixed addressing, which you would typically use for servers, but also for different hosts on your network that would need to know a priori what type of address or what address they're getting, whether it's for firewall rules or other access control or for other types of address management purposes. So for the fixed addressing we're basically using a 64‑bit host identifier. And it's all leading zeros up and to the last grouping which then you encode the last octet of the IPv4 address using decimal encoding so you can ‑‑ so it's ‑‑ you can recognize it with ‑‑ human recognizable, I should say.
And then for dynamic addressing, basically that's going to be done using DHCPv6, and we chose this over slack, again, so we could know from a managed enterprise perspective what hosts were going to be getting what addresses. Excuse me. This is the dynamic portion of things. But the idea was to be able to know which clients we would expect to be asking for them, I should say, rather than having the host do their own configuration.
So in terms of address configuration, I already mentioned the manual host, and this would be for fixed addressing, mostly for servers but also for hosts that needed ‑‑ that we needed to know which address they would be getting. Then for the automatic configuration, we would be using basically a /96 pool, address pool, to be given out at random. And this is in support of an IPAM‑type environment. And also this way we wanted to ‑‑ we wanted to use as much of the IPv6 infrastructure as we could. And with no current mechanism, at least, that's broadly deployed for advertising DNS servers in slack, that was ‑‑ it was also a way to be able to utilize IPv6 DNS servers using DHCPv6.
That was one of the motivations for this, and we also wanted to be able to, using DHCPv6, have the capability for those hosts assigned dynamically from the pool, for example. We wanted to be able to have their reverse addresses registered in DNS so that, using whatever types of network diagnostic or analysis tools, we'd be able to quickly see what host that is that's generating certain traffic. Those are some of the things we set up in part based on our requirements. And the way our architecture is set up is fairly straightforward. But basically we have a DMZ‑type environment with several environments behind that. And all that is behind our border router.
And, interestingly, before everyone ‑‑ when you're deploying this in the enterprise, people are scared, what's this IPv6 thing. How do we know it's not going to break everything. So one of the things we did was actually test up a testbed environment that hangs off our border router so that we were able to get v6 connectivity to the Internet before it ever came into our networks and do some testing there, and that's where we were able to do a lot of experimental things and break things, test routing, do all sorts of things out there without affecting our production networks. And also in terms of how we phased our deployment, we're able to use this environment to show how we were going to basically work things from the outside back in.
So starting in the testbed we were able to do some things there, bring it over to our border router and then start peering with our upstream provider, who is ESnet, actually, and then bring it back into the DMZ where we have a lot of our network services DNS Web servers, Web proxies, and finally bring it back into where the clients are and other servers. In terms of the security, we've blocked a number of the typical things at the border, which I have listed here, fairly straightforward.
Now, coming to some of the challenges that we've come across as we've done this, looking at different implementations on both the host and at the network level with some of the firewalls that we've used, some of the challenges that we've come across. I should mention that as we're doing this and deploying IPv6 we've really been trying to not make it so that in order to get it to work on your client you have to do all this crazy configuration. It's kind of balanced in this kind of awkward way. What we really wanted to do was see how well things worked out of the box and do kind of a least configuration approach that we could using the architecture we set up with DHCPv6.
So at our network level, we had a lot issues with this application‑level gateway that was turned on by default. Specifically affected fragmentation and getting the fragments back. And that affected mostly DNS and DNSSEC responses. Fortunately we did a lot of thorough testing before we turned things on, and so we discovered this and had to troubleshoot what it was and find ‑‑ pinpoint what the exact problem was. What we ended up doing was turning off the application‑level gateway for the things that were most affected by it ‑‑ or the things that were affected by it, excuse me, and that's DNSSEC in particular.
We also found, as I mentioned, some of the firewall problems on the hosts with Red Hat 5 which uses Linux kernel 2.6.18. We found that we also weren't able to get large responses if you were using IP tables because the fragments wouldn't be accepted back. So we ended up having to turn off IP tables and just turn off the unnecessary services and handle things that way. With Red Hat 6, DHCPv6 responses weren't returned using the standard rules that you would expect as a related response. And so we had to have some workarounds to change that, to get it to work. The big thing to take away here is, as you're deploying, to test fragmentation and large responses. In terms of configuration, fairly standard, but we set up our RAs to set the managed bit and also to clear the A bit on the advertised prefixes so that our clients would not autoconfigure. And actually so far we've discovered that they obey that quite well in our testing. We don't have any that are self‑configuring that we've seen so far.
Of course pre‑Lion, OS X does not support DHCPv6. Windows XP doesn't support DHCPv6. And in terms of DHCPv6, we've had several issues, at least with the implement that we've used. Well, I understand there are other implementations out there. We were using what we had been using for DHCPv4, but the feature set isn't quite as rich. And particularly one of the things we'll have to do is populate our IPAM with do it for each device rather than the Mac address, which is already in there. There are some retrofits in there, but the problem is it's not really a robust long‑term solution. So that's something we still have yet to do. And of course it also changes the functionality. If you have multiple interfaces per device, how does that ‑‑ are you expecting a different IP address based on the interface you're getting and so forth. There are a lot of numbers, issues to be worked out there.
The pool statements, at least at this point in the implementation, aren't usable within subnet6. So you can't allow and deny clients based on the existence of a host statement. And then there's some issues with updating both A and quad A records using DHCPv6, or at least using the current update mechanism. So just some observations. I'll summarize this quickly. Windows 7 is actually the ‑‑ believe it or not, the best behaving out‑of‑the‑box DHCPv6 implementation that we saw, as in it would work as expected and actually put the IPv6 DNS servers before the IPv4 servers. OS X Lion worked quite well, but actually put the v4 servers first. The other ones required a little bit of weird configuration to get them to work.
And then one final slide here, and then I'll wrap things up. One of the things that ‑‑ what was quite nice is that we had some application ‑‑ some appliances at our border that we were able to go out and have our clients get v6 connectivity over the Web because they were able to use a proxy that had v6 connectivity, a proxy http appliance. There are a couple of issues with this, of course. There's some ‑‑ I guess this is a feature that it doesn't fail over to IPv4 in the case of IPv6 connectivity or proxy appliance here.
Works well for identifying others' IPv6 issues, but unfortunately it requires then us to hear it from our users and to go in and change that. We're working on some automated process to actually kind of do detection of who's working over IPv6 and who is not. But then we also found that kind of independent of this there's a bug where if we have some kind of problem with our physical interface, it loses its IPv6 route when it comes back up, which means we don't get access to anyone who has dual stack, not just if the problem is on their end. So that's been quite unfortunate.
And case in point, www.bluecoat.com was unacceptable, last time I checked, over IPv6, which means that our vendor ‑‑ we weren't able to get to their website if we were using IPv6 from their device. So a little bit of irony there. So I think that's all I have. A couple of minor things there, but I'll wrap things up here. So thank you.
Aaron Hughes: Thank you very much. Next up we have Michael from ESnet, talk a little bit about government and education.
Michael Sinatra: I hope everyone got a chance to get pictures of the IPv4 address that was on the projector. I saw some people trying to snap pictures of it. I did intend to dress up for this. I thought I packed a really nice shirt; apparently I didn't. I was going to look as nice as Casey does, but I instead have the same old Patagonia fleece that's about ‑‑ since ARIN XV I've been wearing this. I apologize for that. I'll go through the slides quickly. There's the table of contents. And I'm going to talk a little bit about the way in which networks are supported in particularly research and education, because you got to see a government example already with Casey, sort of a government enterprise, one of the national labs, which is what I work with quite a bit. Casey's one of my customers.
I'm going to talk a little bit more about EDUs, but the important thing to understand is there are different ways in which EDUs are supporting their networks. Some of them are highly centralized, some of them are highly decentralized, and some of them are sort of in the middle. And it turns out a lot of these middle models tend to work better for IPv6 deployment because you can start deploying piecemeal, you don't have to turn it on on the whole the network at once, and you don't have to worry about the fact that department X is still running a Proteon router and that's the only thing they have and it's connected by some token ring thing or something like that. So it's a lot easier to do it when you have sort of a hybrid model that tends to, at least in my experience, make v6 deployment look better.
By the way, I should say that I'm taking some of this information both from anecdotal evidence ‑‑ I solicited stories from various EDUs and government agencies ‑‑ and I also have done surveys. So there's some survey data in here, it's sort of mixed in, and there's some anecdotal information in here. I've of course hidden all the names, except for the ones you see right there, which I've put some examples here. This is what normal people refer to as a matrix. It's what abnormal people, I think, call a magic quadrant. And so really where you want to be is down in the lower right corner there.
And I think Virginia Tech is getting there. Sorry, Dave, I didn't put University of Minnesota up there ‑‑ well, he's gone anyway, so I don't care. Never mind. What I'd like to see is this move. These are just sample universities. They're not all the ones that are doing IPv6. There's many, many more. But I'd like to see these guys moving towards that lower corner. And when I presented this a year and a half ago in a panel that Cathy arranged, I don't think there's been a whole lot of movement here, which is a little bit of a concern to me, and I'm going to talk a little bit more about that. Hopefully some day there will be an unintelligible blot all the way down at the lower right corner.
So one of the things that's helping moving IPv6 deployment in the government ‑‑ and I talk about this, and I always assume people know it, but I don't know if everyone here knows the mandates that have come down from OMB and the federal CIO, but it basically means that you have to have public‑facing sites be IPv6 capable by the end of this fiscal year and that you can do proxies and stuff like that. But by fiscal year 2014 you need to have everything completely native. So that's what government, your friends in government, are working on right now. And that's got them really concerned.
There are a lot of agencies outside of the DOE agencies that Casey and I work for that are doing pretty well. The Veterans Administration is just going gangbusters. They're telling other people in government how to do IPv6. It's really kind of interesting and very good to see.
And of course I think a lot of people know who Ron Boersma is and know about DREN and how they've supported IPv6, and they've been on the forefront not only of deploying IPv6 but getting vendors to support IPv6 and deploy IPv6 in their own networks. So that's been a really cool contribution that they've made.
And we even have the IRS helping out as well. And you've seen an example of a national lab as well doing IPv6. I talked a little bit about the EDU success stories. Most of those are already in the previous slide. UC Berkeley I singled out because I was there when they did their wireless network, and that was really cool. Dave Farmer has also mentioned that University of Minnesota has ‑‑ part of their wireless network is IPv6 capable. That's really good for getting eyeballs going, and also because wireless networks tend to burn through a lot of IP addresses.
So what's the problem? What's causing us not to go as fast as we should? As usual, of course, it's leadership. It's the CIOs that are the problem. If we just got rid of them, I'm sure it would be a lot easier. But part of the problem is that security is a huge concern for them, and they listen to their security officers. And often their security officers say things ‑‑ with good intentions, actually, say things like, well, IPv6 is a security risk, IPv6 is difficult, it's hard to understand, we need to learn about the new threats in IPv6, we need to upgrade our firewalls, we need to upgrade our IDSs. And so there's a lot of concern about the risks that deploying IPv6 brings to an organization.
In addition, a lot of these same CIOs in both government and EDU are very, very interested in the cloud. They really want to move toward cloudy things and they like clouds and they like outsourcing and doing stuff like that. That makes the network very important. But a lot of these cloud providers don't support IPv6. That's a big issue. And the CIOs aren't thinking about that. They're thinking that if I outsource to this cloud provider, all the problems are going to go away. I don't have to worry about anything. The fact that they don't support IPv6, that's not my problem. That's their problem. So as we see, though, it becomes everybody's problem because the integration issue becomes that much worse when the cloud provider doesn't support IPv6.
So while EDUs were initial in the IPv6 deployment, there's been some stagnation recently. So that's looking again back at the EDU space, the result of this is that we have a little bit of complacency that's happened in this community. And, again, this is me speaking for myself. I want to be very clear. Someone who has been involved in IPv6 for more than a decade, who works for an organization that's been involved in IPv6 for even longer, it's a little bit disheartening to see where we are right now with IPv6.
And when I say "we," I'm talking about the greater community and the community that I sort of represent, which is the government education community. So here you have an example as well, I want to point out, of a cloud provider that's not doing IPv6 and nobody really thought that was important until an announcement was made, hey, we're doing this thing with Box, and somebody asked does it support IPv6. And the Internet2 community was ‑‑ at least some of the technical community was pretty upset about that. But it's been hard to get up to the CIOs and explain the importance of this to them.
There's still a lot of red here. This is Mark Pryor's webpage. I think a lot of people have seen this. You don't want red, you want green. And this is just a little distillation, but there's still a lot of red on that page where the EDUs are and even where a lot of the government organizations are.
So, again, this is just more of examples of the complacency we have and the sort of "Not my problem; this is the network people's problem. This isn't the application developer's problem, this isn't the sys admin's problem; this is the network people's problem." And part of the organization in EDUs is where you have the network group is kind of like an ISP to the rest of the enterprise. I think there are a lot of enterprises out there that work like this, but in particular the network organization really works like an ISP to the students and faculty.
So it's really hard to get the network people to tell anyone else what to do. Because those other people are just your customers. It's really hard to say you have to deploy IPv6. Now, one way to do it is to run out of IPv4 and say, well, there's no more IPv4, you have to do something.
But at that point that's kind of a heavy hammer and you're kind of getting towards the point where telling someone to suddenly deploy IPv6 otherwise a critical system they have can't go online is kind of ‑‑ puts them in a difficult situation. So it's hard to get people motivated at the right time. There also are the remaining technical issues. We've heard a lot about that from Marla in particular and from Casey. But the same thing, you hear the same thing, which is yes, it supports IPv6, but it doesn't do something that you really need it to do. Like it eats ICMPv6 packets that have to do with MTU.
So any kind of packet too big or anything like that where you would need to do Path MTU Discovery, you have load balancers that are supposed to support IPv6 but they just eat those packets. So they become useless when you have different MTUs and situations like that. You've got obviously firewalls and IDSs I think are starting to come up to the point where we're getting good IPv6 support. It's not just a case of, oh, yeah, we support IPv6 but we do it really poorly. Like we don't support stateful IPv6. And now it's getting to the point where we do have very close IPv6 feature parity and IDSs are getting a lot better, too.
Part of it is that we also have management tools, some of which are homegrown, as Marla pointed out. So a lot of those same issues are coming about. And a lot of the homegrown tools have stuff like this in them, like on the second bullet. That's the Perl regular expression. But what it really is to me, it's the symptomatic thing. Whenever I find a script that has this in there, I see this notion of assume that an IP address looks like a dotted quad 32‑bit address. We've made an assumption and we've statically coded that assumption into our code and now it needs to be excised. There are very easy ways to excise it, which is just use the libraries that Perl and Python have already given you that do all that work. You don't need to do those regular expressions anymore, and yet we still do them. We still make these static assumptions about what IP addresses look like.
So that's something we have to get out of our ‑‑ I wish I had like a spray that would just get rid of it, to get that out of our scripts. And I have to constantly go through and work on our scripts and modify them to use real libraries instead of making these ad hoc regular expression matches that end up breaking in the face of IPv6. All right. So in addition to spraying off our scripts, what else am I doing? It's important to understand that CIOs and managers are often risk driven. So if they are sitting there thinking that the network's fine, the network's mature, I don't need to worry about the substrate, I need to start telling them about how they do need this worry about the substrate and what are the risks about not deploying IPv6.
This is a way of presenting a fair and balanced version of the fair and balanced version that they're getting from their security officers and everyone else who is telling them that IPv6 is risky. I have to tell them that IPv6 is risky if you don't do it. And there are some ways in which I think a lot of us understand, but that needs to be brought forth to the CIOs as a real risk. You also need to train the folks who are actually doing the work that IPv6 is part of your job now. It is part of what it means to have a machine on the network. It has an IPv6 address. Otherwise, it's not on the network. For now it has to have both. It has to have IPv4 and IPv6 in order to be considered on the network.
We need to educate people when they put a machine on the network, it means it's dual stacked by definition. And it means your development machines are dual stacked, your QA machines are dual stacked, your production machines are dual stacked, so there are no unpleasant surprises when you go to put something in production and your IPv6 evangelist says, hey, this is a public‑facing service, why doesn't it have IPv6, and you have to go back and fix a bunch of things that broke because you didn't use IPv6 from the beginning and you didn't know what was going to go wrong. And that's about it. Thank you.
Aaron Hughes: Because of the nature of the Comcast switch, we don't have a Comcast presentation. And we're going to have some prepared questions to start, but I think because of the lack of time we can go ahead and open it up to audience questions. Unless you want to ‑‑ Dan, do you want to contribute anything that was missed along the...
Dan Alexander: I think it would be good just to open it up to the floor and make it more interactive.
Aaron Hughes: All right. Questions? Paul.
Paul Vixie: Paul Vixie, Internet Systems Consortium. Casey, I saw your slide again on DHCPv6. I want to point out that when we started working on it, everybody thought stateless was the way to go and we were criticized endlessly for working on DHCP 6 at all. We completed it using funding from selling support on DHCP for version 4. We now, years later, have a DHCP forum, and we invite people who care about DHCP 6 to either join that forum and help fund and decide what we do, or to join the BIND10 effort because we're integrating DHCP into BIND10 and that will be v6 from the get‑go. Any of the missing features or bugs that you mentioned today are high on our priority list of things to care about, but not necessarily high on our priority list to spend money we don't have fixing. So thank you for bringing this to everyone's attention.
Casey Deccio: By the way, I should mention I appreciate all the efforts that have gone forward thus far, and what I presented today was kind of the current state of things, and I realize there's not just ‑‑ it's not just things specific even to the implementation that I was talking about, ISC's implementation, but there are a lot of things that are actually, as Paul mentioned, in the working groups as well in determining, for example, the DoIt versus the MAC address thing and how you deal with that issue. These are things that are being worked out in the working groups as well and are not even ‑‑ many of them not even implementation‑specific. But they are challenges we're facing. So thank you, Paul.
Aaron Hughes: Cathy.
Cathy Aronson: Cathy Aronson. I wondered if you guys ‑‑ there were a whole bunch of presentations at IETF about this World IPv6 Launch thing, and I had looked through the criteria for that, and it seems like there are a lot of ISPs that are completely IPv6 but they may not have one percent of their traffic fee over v6 for like a really long time and that kind of excludes them from actually being a real participant. Anyway, I just wondered whether you guys were participating, if you could say what you thought, do you care, whatever.
Dan Alexander: Comcast is participating and the expectation is to meet the requirements, so we should be there.
Marla Azinger: Frontier Communications is not because we will not meet that requirement. And one of the interesting things, that requirement has been discussed between several unnamed ISPs, including mine, the only named one, of, well, let's look at that wording and how can we manipulate what that says in order to qualify and be able to say we're going to participate.
I decided: Forget it. It's not worth it. Because I don't want to play word games and, hey, if someone can actually get that much traffic when you take their network size and get it going, great. But we don't ‑‑ like I said, we don't have time to be doing the publicity stuff. And to me right now the v6 day is more a publicity thing and a distracter. So we're not.
Michael Sinatra: From ESnet's perspective, that's a really good question because we're mostly a backbone that then provides services to people like Casey. So it's really a question of whether 1 percent of Casey's eyeballs have v6 connectivity, and that's not a question we have a very good answer to right now. We are I think planning on participating just as the fact that our website has IPv6 and sort of as a content provider, even though there's not much content we provide, but I don't think we're going to legitimately be able to participate as a network operator because I don't think we have a good idea of ‑‑ I don't think we can say authoritatively whether we have that 1 percent.
Aaron Hughes: Thanks. So one of the interesting things to me is that we're listening to a wide variety of types of organizations that are implementing v6. We have enterprises, service provider, DSL, cable, government, educational institutes. And nobody's up here saying dual stacking their networking is hard.
Everybody is talking about vendor management. It faces every edge, whether you're looking at enterprises and firewalls or you're looking at providing network transport to customers. We're talking about managing vendors. How much of your time do you think you spend on vendor management as a whole for implementing v6?
Marla Azinger: You can't stop. It's ‑‑ it's ‑‑
Dan Alexander: Well, to single v6 out regarding vendor management is kind of pointless, because most of our jobs are vendor management no matter what the topic is. Pick your technology and a fair amount of it becomes vendor management. It's just a matter of whether it's v4 or v6. It's driving the prioritization of what gets developed fastest and first and working through the bugs from there.
Marla Azinger: I think one thing that people need to know with vendor management, it is time‑consuming, but disperse who is doing what as far as getting after the vendors, because you're going to need your higher‑level execs actually contacting those vendors and saying we need this to work for what we need to use it for, and you don't have it and we need it and we want it by this date. If you can get the higher execs to at least call them, talk to them and say we need things by this date, you're going to be a leg up and not spending as much time talking yourself blue with those vendors saying this is what we need, get it in my lab by here. And they'll go “oh, roadmap.” I swear to God, if you hear the word "roadmap," just like automatically turn around and go higher up your chain, because roadmap's like a buzzword for going nowhere.
Michael Sinatra: Although, it's even worse when you hear we're not doing IPv6 and we don't have a roadmap. Which is what I heard from Box. That's what they said publicly, is we don't have a roadmap.
Marla Azinger: We have some vendors like that.
Dan Alexander: Coordination is very important because it's a lot easier to have a conversation with other participants in your industry, and everyone having a unified voice towards the vendor saying these are the feature sets or these are the issues that are high on the list, as opposed to any particular vendor hearing nine different stories. Everybody has their own flavor of what's important. But to bring it together in a better prioritized list definitely helps bring the vendors in line.
Aaron Hughes: Are certification organizations helping that, or are the certification organizations too disparate to really pull it all together?
Marla Azinger: What do you mean by certified organizations?
Aaron Hughes: For example, there's a cable lab certification program, there's software certifications, there's v6 website certifications. Are they helping drive vendors to a solid, well‑defined set of features that actually certify them as v6 ready?
Marla Azinger: I think there's a lot of good intent out there by those and they're trying, but when it comes down to it, it matters what the user is telling the vendor they need. And there are still some vendors ‑‑ it wasn't too long ago where another vendor told me, well, no one's asked for this.
Michael Sinatra: That's one of the reasons why it's good to have the coordinated response and the coordinated list of requirements, because vendors always do that. And it's really nice to be able to tell them no, everyone else has asked for it, because we talk to each other and we know people who have asked for the same feature. But that is the hardest refrain to hear. I totally empathize with that.
Aaron Hughes: Well, with that, I thank all the panelists for their time and sharing their experiences with us. Please give them a hand.
John Curran: Excellent panel. Thank you.
John Curran: Okay. 2011‑1 modify section 8.3, Transfers to specified recipients, to allow specified transfers between ARIN and RIRs that have compatible, needs‑based policies. A /24 minimum. History. Originated as ARIN Proposition 119, was presented at ARIN XXVII, revised and presented at ARIN XXVIII. Revised text sent to extended last call in October. And the AC recommended adoption of it in November. The Board of Trustees took the recommendation under advisement pending discussion at ARIN XXIX. Board also directed ARIN to prepare for implementation. It was not approved by the Board, but the Board directed ARIN to start on the implementation and took it under advisement. Current version is the post meeting 14 October 2011 version. The text and online assessment are online and in your Discussion Guide.
Draft Policy 2011‑1 Board Direction. The ARIN Board of trustees takes the recommendation of Draft Policy 2011‑1: Inter‑RIR Transfers formally under advisement pending a final community discussion at the ARIN XXIX Public Policy Meeting in Vancouver, British Columbia. Furthermore, the board of trustees directs the president immediately start implementation of this policy in parallel, with final policy availability to be held until otherwise directed by the Board. This is not our typical adoption motion. The Draft Policy 2011‑1 had extensive revisions for clarity after the ARIN XXVIII Public Policy Meeting.
We actually looked at our ARIN Public Policy process and the revisions are allowable. It's the discretion of the AC to some extent in the current PDP. There's actually a work item for the revised PDP, future PDP, to look at some of that because this wasn't probably something we want to do all the time. Not if it requires motions like this. But the fact is it is compliant with our current PDP. And an extended last call is what's recommended and what was held to accept comments on the changes. The Final Community Consultation on these changes is today.
I'm going to ask actually one specific question that we're looking for comments for, and then I'm going to open it up for all comments related to 2011‑1, but I ask for people initially to constrain themselves and come to the mics for one very important question, because many of you were involved at the meeting, on the Mailing List, and you saw the ARIN XXVIII Public Policy Meeting consultation we did where the policy was put up and it was discussed at length. Since that time it's been edited, and the question that we really need to know is: In the process of editing for clarity, is there anything that was left out or anything that was inserted into the new policy text that wasn't really for clarity but was something else. So we're really interested in, first question and the primary question is, is there anything that was left out or inserted while these clarity changes were being made. That's a very important question for the Board to know. Mics are open. I ask people to come up and address.
Tim Denton: Two minutes. Two minutes and stick to the point with something that John raised.
Bill Sandiford: Bill Sandiford, ARIN AC. Since you're asking if there's anything left out or whatever, is it possible to have the original and the proposed before us? Because I've got a pretty good memory, but I only have the current proposed. I don't have the old one anymore. Is it possible to get that up?
John Curran: We can put one up. And if you want us to put the ‑‑
Bill Sandiford: Can you put the old one up and we have the new one in our guides.
John Curran: Can we put the old one up based on the Draft Policy archive? It might be a fairly small font to get it entirely up on the screen.
Bill Sandiford: Thank you.
Chris Tacit: Chris Tacit. I'm just wondering if more clarity could be given to compatible needs‑based policies. I feel that's something that's omitted in terms of providing ‑‑
John Curran: The question we're first asking at this moment is on compatible needs‑based policy, which was in the old one and in the new one, did somehow the criteria change in the rewrite in a way you want to point out.
Chris Tacit: Just between the draft changes.
John Curran: Simply asking about changes from the old text to the new text.
Chris Tacit: All right. My question is there isn't a definition, and that's it.
John Curran: Understood. There's no definition. We know that. We're particularly focused right now on a discussion of changes that occurred. If some aspect of the policy was left out or some new aspect was introduced, that is fairly important for us to know on the Board. Remote participants, you're welcome to come in as well. Microphones remain open for this.
Scott Bradner: You should specifically ask for comments if they don't think anything is changed. There's got to be an opinion somewhere in this room.
John Curran: So no one's identified any changes. I guess we should ask, Scott points out, folks who would like to comment on the sameness of the policies, okay?
Scott Leibrand: Scott Leibrand, ARIN AC. I was responsible for a lot of these changes. Tomatoes welcome my way if you don't like them, but my goal was to make them the same, so I would love to hear anything to the contrary, but to my knowledge they're as close as we could get them to the same while fitting within 8.3.
John Curran: Thank you, Scott. Front and center.
Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. I believe that we managed to accomplish the same intent while making the language quite a bit more clear. It is unfortunate that that required a significant restructuring and rewrite of the text, but it did, and we did it. And I think we achieved the desired result reasonably well. If anybody feels otherwise, please do comment. This would be the time to do so.
John Curran: Back microphone.
Marla Azinger: I was still reading. So sorry. I just found one thing that looks like it was taken out, which is the 24‑month utilization. So where did that go?
John Curran: The 24‑month utilization.
Marla Azinger: I'm comparing what I believe is supposed to be the current NRPM that's in the packet with the Policy Proposal Statement Packet. And 8.3 in the current NRPM, the very last line says 24 months.
John Curran: Want to compare this policy to 2011‑1 in your packet.
David Farmer: David Farmer, University of Minnesota, ARIN AC. That was a different policy that was approved in the interim that makes the changes she's referring to.
John Curran: Right.
Marla Azinger: Does that disappear?
David Farmer: That would not be our intent.
Marla Azinger: That's what I needed clarified.
John Curran: Rear microphone.
Andrew Dul: Andrew Dul, Cascadeo. I'd like to commend the AC on the rewrite. I think it's very well done and fits with what was discussed in the last meeting.
John Curran: Thank you, Andrew. Other comments? That's closed. I'm going to open this up to any other Board consultation you folks or guidance ‑‑
Scott Bradner: I would suggest you declare as far as the room is concerned the consensus is there's no significant difference between these two; that the ARIN AC did not muck it up when making the changes.
John Curran: Given the conversation, we're going to declare that there's no substantial difference between these two. If anyone wants to speak on that. No? It is so declared. We are opening up now because this is a consultation and this matter is still before the Board, we know some people may want to have ‑‑ this is already recommended policy and the Board asked for an extended consultation to the extent you want to speak on 2011‑1 at all, the microphones are open.
Chris Tacit: I think the clarification that staff provided could form a basis for actually clarifying that in the policy itself. And I just had a question, too, and that is to what extent has this been compared to other IRR policies that we view or might not be compatible to work out any bugs that might arise among them so that we don't run into implementation issues when this goes into effect.
John Curran: So staff implementation is going to be true to the comments you saw, as you said, staff postulated in the comments what compatible needs‑based would be interpreted.
While we're aware of other policies in other regions, we consciously did not do an assessment of whether this locksteps with any other regions policies because those are in flux as well.
Last time I looked, I noticed APNIC had one. It looked to be compatible, but I haven't been on an airplane recently over that way so I don't know if it's changed since. But the staff implementation will match the notes you saw in the staff review. Can we move to a new one now? Thank you, Scott. Does that answer your question?
Chris Tacit: Yes. It was a question whether it might be better to put those words in the policy rather than leave it to interpretation. That's all. Unless there's a deliberate effort being made to create a bit of wiggle room after we see what the other IRRs are doing.
John Curran: If that's put in the policy, and that could be, if that's what the room wants, the room could advise the Board not to advance this policy and instead to remand it to the AC to have that done. Is that what you're suggesting?
Chris Tacit: Not necessarily. Just asking the question.
John Curran: If people want to speak about that, the microphones are open. Rear microphone.
Mike Joseph: Mike Joseph, Google. I wanted to point out, of course, most people here are aware that there's another policy on the docket, 2012‑1, which covers much of the same material. And I wanted to make a request of the Board, if 2012‑1 passes or garners significant community support during this meeting, would the Board consider delaying implementation of this policy, 2011‑1, so that the 2012‑1 could progress and become the policy that ultimately adopts.
John Curran: Point noted. Microphones remain on 2011‑1, if anyone would like to comment. Front microphone.
Kevin Blumberg: Kevin Blumberg, ARIN AC and The Wire, speaking on behalf of myself. I absolutely agree that we should hold off if possible on this one until we've dealt with 2012‑1. I don't think there will be a huge time delay. Back when we had this last discussion, I still have a concern. I'm in support of this proposal, but I still have a concern that if we find this region is affected by this policy, that by the time, as there is no safety valves in this policy, at some point it will not be possible to stop it. And that is my concern; that from a ‑‑ and the lawyers back there, from the liability point of view, once it's been allowed, you won't necessarily be able to take that away. And that is my concern; that there is no safety valve in this; that once it goes into effect, if we find that it's being ‑‑ adversely affecting this region, as an example, that we can turn it off.
John Curran: And that's good feedback. You do support this and you're advising the Board to continue with its adoption, but you note that it doesn't have its own safety valve.
Kevin Blumberg: Correct.
John Curran: And the PDP, current PDP has provisions for emergency policy suspension, which are effectively in all policies, since the Board has that power. Those aren't sufficient for this purpose?
Kevin Blumberg: I don't believe it's sufficient for this purpose.
John Curran: I'd be interested in your insights on that. If you come talk to me, I'll make sure they get written up in a way for the Board.
Marc Lindsey: Marc Lindsey, and representing LBBB outside private practice law firm. My question is: Would the staff make a predetermination as to which RIR policies exist, or would this be on a per‑request basis?
John Curran: We would be making a single ‑‑ when policy was brought to our attention ‑‑ and we do track the other policies ‑‑ we'll make a single determination and publish it on the website saying that the following policies are known to be compatible, and so it would not be per request. It would be as other RIRs update their policies.
Marc Lindsey: Thank you.
John Curran: Microphones remain open. Yes, Counsel.
Steve Ryan: I'd just like to say that I think I want to reiterate to ARIN that this policy is important from a legal perspective and puts the organization at risk if we do not have a policy that allows interregion transfers. We're going to face a situation in a bankruptcy court where the highest bidder who is qualified in their region and has a corresponding regional policy that would permit transfer, if we don't have a policy that permits transfer, it will be a heartache, it will be expensive, and so I think this policy is legally very useful to ARIN at this time.
John Curran: Microphones remain open on the matter of 2011‑1. They remain open. I am closing the microphones. Approach the mic briskly. Remote participants, last chance for comments. The microphones in the room are closed. Remote participation is closed. Thank you very much.
Leslie Nobile: All right. Good afternoon. So this is the first look at this IPv4 countdown plan, otherwise known as depletion planning. We still have roughly five /8s, as you all know, but we thought the earlier we started this the better, the better informed and prepared we would be and you all would be. Our plan is to keep you informed as we add in further detail. So we'll just start. We're going to take a phased approach. We're going to have Phase 1 through 4.
Current phase is Phase 1. It was initiated when ARIN received its last /8 from IANA. I'm going to go into the detail further in the presentation. This is just a quick overview. Phase 2 will begin when ARIN has three /8 equivalents remaining, Phase 3 will begin when ARIN has two /8 equivalents remaining, and Phase 4 begins when ARIN has one /8 equivalent remaining. So there's some things to keep in mind as we go through this. There's sort of variables. Things could change fairly rapidly. It just depends on what's going on in the outside world.
Some of the IPv4 space that ARIN currently holds in its inventory may be returned to IANA in accordance with the global policy that is currently before the ICANN Board. We're not sure. But it has been ratified in all five of the regions. And it says that any of the RIRs have the option to return space to the IANA, space that it gets back from the community. There are new policies that could be implemented and/or large requests that could come in from the larger ISPs that could change the intended plans and lead to faster depletion of the v4 pool.
I think there's a policy that's been discussed this week that will change the allocation window from three months back to a 12‑month supply, meaning that some of the larger ISPs could qualify for much larger allocations, and of course really hit our available pool very quickly. The waiting list could kick in. There's a waiting list policy that says when ARIN can no longer satisfy a request, there will be the option of going onto a waiting list. So that sort of adds some complexity to this whole thing. And it could kick in during any one of our phases, just depending on our available inventory.
I can tell you that ARIN has lots of smaller aggregates left, lots of the /20s and /23s and /24s. We have very few of the largest aggregates left, the/8s, /9s, /10s, and /11s. So those larger ones will go quickly. And once we have no more, we won't be able to issue any more and the waiting list will kick in because, I think, as most of you know, there's a policy in effect in the ARIN region that we can only satisfy a request with a single aggregate, not with multiple aggregates, multiple prefixes. And then our two‑day turnaround time. We try to keep things to under two days for turning around and responding. This may not be possible as we move further into this depletion planning and we change the way we review requests.
Phase 1 went into effect in February of 2011 when we got our last /8. That is when the three‑month‑allocation‑window policy went into effect, and we've seen a real slowdown in the allocations we are making since that time. All requests are now peer reviewed. Every single request, no matter what size it is, gets reviewed by one of the analysts, by two analysts, let's say. The larger blocks require sign‑off by a senior analyst review and sign‑off by a senior analyst and/or me as the department director. The space that we needed for some of the policies has already been pulled, reserved from our available inventory. So we don't have to worry about that going down the road.
We have a /10 reserved for the IPv6 transition policy and we have a /16 worth of space for microallocations. And currently our returned, reclaimed, and revoked blocks are held for six months. I think you all know that we wait for filters to clear before we reissue space. So that is where we are right now still doing that. Phase 2 is going to begin when ARIN has three /8 equivalents left. That could happen at any time, actually. We're doing this early so we gain experience. So we're going to have team review by the senior analysts for only the largest requests. The /16 and larger requests will be team reviewed. Everything that we do is going to be a first in/first out by date and timestamped. Basically what John was referring to as serialization, and this is going to apply to both the initial requests and then the responses.
Whoever gets in their response quickest is going to be reviewed quickest, that's how it's going to work. Once we go through the back and forth and make an approval, that's going to basically be our trigger. The recipient's going to have 45 days to complete the payment and/or sign the RSA if that's necessary. The space will be released back to the available pool on the 46th day, if the transactions have not been completed. So this is really new, and it's probably a little controversial, because right now we hold things open for at least 90 days, but this is going to change. The returned, reclaimed, or revoked blocks that we hold for six months will now drop down to three months. So we'll only hold them for three months, to clear the filters, and then we'll release them back into the available inventory.
And the peer review continues, the sign‑off continues on the larger requests. So Phase 3 begins at two /8 equivalents, and there's no external changes whatsoever. This is the time for the staff to re‑examine the processes, make sure they're working the way we need them to and make any modifications and tweaks as needed. We'll continue the three‑month hold, the peer review continues, and the sign‑off by the director on the larger requests continues.
So Phase 4 is when things really do change. That begins when we have one /8 equivalent remaining. So everything will be first in, first out by date and timestamp. And that's going to apply to all requests of all sizes. So it's the smallest to the largest. All the requests will be team reviewed. So we haven't really worked out the details. So hopefully no one will ask me questions about this, because I'm not quite sure what we're going to do. But the concept is everything gets team reviewed. That way one analyst who may work faster than another analyst doesn't get ahead of the game. We want to make sure that everything is absolutely reviewed by the book in accordance with the date and timestamp.
This hold bucket we have will cease to exist. At this point we won't have any choice. There's not going to be a lot of space left so we don't have the luxury of holding that space for that six months or three months. So the plan is to get anything revoked, reclaimed, returned, it's going to go right back into the available inventory. So what we will do, though, is we're going to continue to check the routing and the filtering on the space that we're going to issue. And if there is a problem, we will absolutely notify the recipient if there are issues. And you know then they'll have a choice of taking it or not taking it. I think that's all I have. This is, as I said, a quick, high‑level view.
John Curran: Microphones are open.
Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. So these phases begin when you have N /8s where? In the available pool that you're allocating from or in the sum of the available pool plus the whole pool? Or what?
Leslie Nobile: The plan is in the available pool. So /8 equivalents.
Owen DeLong: Phase 4, when you get down to one /8 and your hold bucket ceases to exist, you'll actually jump back up to more than one /8?
Leslie Nobile: There is that possibility. As I said, I'm not sure about the details. That whole /8 equivalent is pretty tricky at this point anyway. So tracking it it could change from day to day. It's going to require some ‑‑
Owen DeLong: That's part of why I'm trying to understand the process.
Leslie Nobile: It will require some analysis. We don't have that nailed down, quite frankly.
Owen DeLong: Hopefully it will be published.
Leslie Nobile: That's one of the thing I left out. One of my first points was we plan on sharing all of this information as we move along. As we add detail, we'll be sharing this with the community. We'll tell you every step of the way what we're doing, when new phases are initiated.
We'll be communicating that via announcements, and we also are putting up a Web page, and that's going up pretty much right after this presentation, now, pretty much, and it's going to be dedicated to IPv4 depletion and countdown planning. This kind of information will be on the Web page right away. As we add detail, it will go into that Web page. You'll be able to track exactly what we're doing.
And the other point is we've been working with the other RIRs who are also going through depletion planning, sharing information, gaining, understanding their experiences. APNIC has gone through this first, and so we do exchange information so we're aware of what's going on and know sort of what to expect. Kevin ‑‑ Marla was next. She's in the back.
Marla Azinger: First I want to say thank you because seeing how you're thinking through it is helpful and appreciated. I have one question on the billing part. It looks like you guys came up with the 45 days for some reason. I want to ask why and then share with you why I'm questioning it. So how did you come up with the 45 days, reducing the payment period to 45 days?
Leslie Nobile: Well, we don't really have the luxury of waiting for months and months. It's going to be critical to get these resources out the door. If somebody's faster than someone else, how do you justify holding it open for three months or four months? I mean, it's just ‑‑ we thought that was a happy sort of equivalent, happy medium there.
Marla Azinger: Okay. POs are a pain in the butt.
Leslie Nobile: We understand that. We do.
Marla Azinger: I've seen them take from what should be really only 30 days to three months. And I guess I if you're stuck on 45 ‑‑ 60 would be more of a compromise.
Leslie Nobile: That was an initial thought. We thought about that.
Marla Azinger: I prefer to see that go to 60.
Leslie Nobile: That's good feedback.
Marla Azinger: Also what could help, PO ‑‑ all of that paperwork, you don't get the piece of the bill, I guess. You need to give the bill maybe even before justification is completed. Maybe there's a disclaimer on it. But if someone has a bill to start processing through the PO, because you can cancel the PO and not actually permit the payment through the PO if something goes awry. But we need to do some things that actually enable people that have long PO processes.
Leslie Nobile: I'm glad you gave us that feedback. We'll take it back and talk about it. Thank you.
Marla Azinger: Thanks.
Leslie Nobile: Kevin.
Kevin Blumberg: Thank you. Thank you, thank you. Two comments. Phase 4, the hold bucket ceasing to exist. Just as Marla has an issue with POs being too short, I have an issue with that being way too short. The reality is that mistakes happen, and having a zero day when space is reclaimed for whatever reason means that mistakes cannot be corrected. Even 15 or at most 30 days would give us sanity. Because if somebody has a space that they had for a long time and a mistake happens, oops, sorry, it's gone, you can't have it back, I don't feel comfortable with.
Leslie Nobile: That's good feedback. Thank you.
Kevin Blumberg: The last thing was we all run businesses, many of us run businesses in here. Personally I get annoyed when people say we can't pay for something that we absolutely need but we can't pay for it because of logistics. If the company at the executive level knows that they're not going to have new customers because they didn't pay a bill, they will get that bill paid pretty damn quick. I think 45 is very fair.
Leslie Nobile: Thank you. Mike.
Mike Joseph: Mike Joseph, Google. I want to echo the former portion of the comment concerning the zero‑day hold period. I think that's incredibly dangerous. I don't know how much space were coming ‑‑ having come back into the pool, but I'll point out the day before it came back into the pool it wasn't there. So deferring the time before it's reissued for about 30 days seems reasonable to me.
Leslie Nobile: Okay.
Mike Joseph: I'd like to strongly advocate you consider that.
Leslie Nobile: That's good. Thank you.
Mike Joseph: Thank you.
Leslie Nobile: I think Jason's next.
David Farmer: David Farmer, University of Minnesota, ARIN AC. One question on that hold time. The RSA and in particular the LRSA have contractual pieces in it. Is that minus ‑‑ does that go away? Do you still have those contractuals?
Leslie Nobile: Does not go away. It's added in beforehand. This doesn't kick in until after that, whatever the RSA says.
David Farmer: To help folks that were having issues with this, there's still the contractual obligations that ARIN has on that getting it back thing?
John Curran: Right. It's a contractual hold cure period in your contract for nonpayment that doesn't go away.
David Farmer: This is after that has expired, ARIN is still currently keeping it for six more months.
Leslie Nobile: Correct.
David Farmer: So this returns that part?
Kevin Blumberg: My issue is that many times problems are not solved until something gets turned off. That's the issue for me. So if at six months nothing has happened and you finally pull the plug on that space, and you get a call the next day, that is what will happen. Unfortunately, in six months it would be great if it's three months and one month or something like that, but I really believe that hold bucket should be there.
John Curran: Can I ask a question? So after the three months or six months, whatever, and it's reclaimed, and now something's going to happen, because it's been reclaimed, how many days to get the phone call to fix it? Two, seven, 14?
Kevin Blumberg: Incredibly, when I shut off a customer, I usually get a call within five minutes to two days. But there have been times where customers were skiing in wherever and two weeks have gone by and they didn't realize it. So 15 to 30 days for me is a fair number.
John Curran: Right. Particularly because we don't turn off connectivity, we just reissue it, and it's only when something starts breaking.
Kevin Blumberg: You turn off reverse DNS, correct?
John Curran: That's true, but a lot of people don't notice.
Kevin Blumberg: You're right. It gives them the time.
John Curran: So you're saying 30 days, 14, 30 days, somewhere in there?
Kevin Blumberg: I still say 30 days.
John Curran: Scott.
Scott Leibrand: A comment directly to we don't turn off connectivity. If I understand it correctly, you do send emails to upstreams letting them know that space has been reclaimed. Correct?
John Curran: We have done that, yes.
Scott Leibrand: So it might be very worthwhile to coordinate your time frames around what you actually see in terms of their processes for getting ahold of people, things like that. That's another way to get at the how long the delay should be, is to ask the upstreams how long they're going to be before they actually shut them off and use that as a basis.
John Curran: We can do some digging into that. But I wouldn't mind hearing from the community what number they like now, because that's a lot more definitive than our research. But understood.
Leslie Nobile: John, can I ask a question? Does the RSA say three months or 30 days? I can't remember what the RSA says. Somebody else might know.
John Curran: It depends on the version.
Leslie Nobile: The newer version is it ‑‑
John Curran: 90 days.
Leslie Nobile: So it is 90 days before full revocation. So what I was saying is our revocation process will be that full 90 days. We will not be revoking ‑‑ we'll be notifying the customers as we do now. We have a whole process where we go back and forth where we're notifying people and trying to find someone to contact to pay the bills, et cetera. So that's still going to be the whole 90‑day revocation window. And that's not even in the hold bucket. That's just ‑‑ do you know what I'm saying?
John Curran: To understand your point, that actually isn't noticed as much as when something's pulled, and the question is do we have a hold period after that, if I understand you.
Leslie Nobile: Yes.
John Curran: Thank you for the feedback.
Jason Schiller: I wanted to ask about the status of the last /8 where each RIR got one of the five remaining /8s which were, in theory, designated for special use determined by each region, how much of that space has already been earmarked for special use and will the balance of that space just be business as usual and count towards this one /8 equivalent in Phase 4, for example?
Leslie Nobile: Right now the last /8 is still available as a full aggregate. We've held it. We've not tapped into it yet. It's the only one we haven't tapped into. But there's nothing in there ‑‑ we've already pulled the space that's required by policy from other ranges. So it's still a full aggregate with no obligations to any policy, no reservations, no nothing. It's clear at this point. Does that answer your question at all?
Jason Schiller: If I understood your answer, at the beginning of Phase 4 when there's one /8 equivalent, it's likely that is the last /8 that we got from IANA?
Leslie Nobile: No, there's no way of knowing that, quite honestly, Jason, because we have a single /9 aggregate right now and six /10 aggregates. If those start getting used, we'll be tapping into this last /8. You know what I'm saying? We don't know.
Jason Schiller: To say it a different way, there's not an additional /8 that's earmarked for special use that's gone away at this point?
Leslie Nobile: No. There's no policy for that. So no.
John Curran: Center rear mic.
Martin Hannigan: Could you go back to Slide 3, please? With regards to the first variable, address space being returned to the IANA, I recall in our conversation with respect to the global policy that while we wanted to go forward with implementation and adoption of that specific global policy, that there was consensus that addresses would probably not be returned or the community did not want them to get returned. Could you shed some light on what the business process would be for any kind of return of address space to the IANA? And I'd also like to support the extension of the financial terms as Marla suggested with regards to the purchase orders.
John Curran: Marty, I'm not sure I understand your first question.
Martin Hannigan: The first question, I'd like you to shed some light on what the business process to return addresses to the IANA would be, if that were to occur, especially in light of the community's consensus not to do that the last time we discussed that.
John Curran: We have a policy in the region that says address space shall ‑‑ that until the adoption of the global policy, address space shall not be returned to the IANA. Address space that is returned to ARIN will not be returned until the adoption of a global policy. At the adoption of a global policy, which is ‑‑ I'm looking for Louie's tophat here ‑‑ which is imminent ‑‑ Louie, how many days does ICANN have to act before it gets adopted on its own?
Louie Lee: ICANN has 60 days from the time when we submit it to them and they confirm receipt of that. That happened during the ICANN meeting, which was roughly four weeks ago.
John Curran: Okay. Thank you, Louie. So in approximately four weeks the ICANN Board will either have ratified, have rejected, or have ratified through inaction that global policy. At that point the ARIN Board can take returned address space and designate it for return to ICANN if that's deemed appropriate. That means thank you to IANA. Address space that's returned to ARIN, now that we have a global policy or once we have a global policy, wouldn't be stranded by its return to IANA. It's entirely the discretion of the Board.
Martin Hannigan: That answers part of my question. What I'm really interested in is how you're going to determine how such an activity is in the interest of the community. For example, 45 /8, or whatever portion thereof that we'd have, I have no doubt that ‑‑ well, it's likely that the global policy will be adopted, but how is it going to work, how is the Board going to determine that it's actually suitable and in the community's interest to actually return any address space? I'd like to see this become less of a variable and more solid and more so so that we can understand how this is going to work. And perhaps we have notice of it if we continue to disagree, we can let you know that and perhaps influence the process. But I think it's important for us to know if address space is going to be returned or not and with ‑‑ to allow us to have some consideration of that.
John Curran: Right. So at the time that that global policy is adopted and returned as possible, staff is going to make a recommendation to the Board to return the return space to IANA, to take the space returned and return it to IANA. The Board has not met and talked about this topic in some time, so I don't know what the outcome would be. But it's quite possible that that remainder of that /8 would be returned to the IANA if the Board ratifies it.
Martin Hannigan: So will you give the community notice if such a thing is going to happen with regards to any address space?
John Curran: Well, I'm giving you notice it's quite likely to happen, and if it does occur we'll inform you the moment it does, yes.
Martin Hannigan: Well, I'm looking to get you to commit to sign up to let us know prior to that happening.
John Curran: It's quite likely in five weeks that will happen. I can't give you notice.
Martin Hannigan: Prior to any addresses being returned.
John Curran: Yes, quite likely. Unless the Board decides that that's not in the interest.
Martin Hannigan: Let me restate my question. Will you be notifying us prior to any address space being returned to the IANA so that we may consider that as a community?
John Curran: At this time, address space returned to ARIN can be returned to the IANA if there's a global policy, and it would be the Board. I don't have guidance from the community or the Board one way or the other. Our default position would be to recommend to the Board to return it. If you think that we should be doing something else, then we need a policy discussion of that. Because we've indicated that we're not adverse to returning that address space as long as there's a global policy that provides for reallocation.
Martin Hannigan: I'm completely confused by what you said, John. I guess I'm going to leave it at that, because I think that we do have a consensus not to return address space even with the global policy in place.
John Curran: I don't think we have that consensus, do we?
Martin Hannigan: I believe that there was a consensus that we wouldn't return any address space and that it was aside from the adoption of the global policy.
John Curran: Okay. Actually, that's a great topic. This is a great time to do it. I want to let Leslie finish, and we'll go into open mic, and the first question should be: With the presence of a global policy, should ARIN be returning address space.
Martin Hannigan: Sure.
John Curran: Thanks. Thank you for raising it. Center rear mic.
Mike Joseph: Leslie, you were kind enough to throw out a couple stats. I think you said one /9 and six /10s. Would RSD be willing to publish the remaining free space broken down by largest free aggregates? In other words, the running number of /9s, /10s, /11s, /12s, et cetera?
Leslie Nobile: Yeah, I was thinking about that. I'm not sure if I have it in my presentation for Wednesday, but I could add it and then it will be available. But I don't know if we're going to be tracking that on a day‑to‑day basis. Right now we're tracking the larger aggregate, the /8 equivalents. But tracking that on a daily basis, it's possible.
Mike Joseph: I would request this, if you would take that as a ‑‑
Leslie Nobile: Yeah, we'll definitely look at it and see what we can do, sure.
Mike Joseph: Thank you. And, finally, when you're talking about these numbers, then you've subtracted already from them the ‑‑ they're inclusive of the final /8 from IANA, but you're not including the numbers from space that's been earmarked by policy, correct?
Leslie Nobile: Correct.
Mike Joseph: What about the Interop block, is that included or not?
Leslie Nobile: The what?
Mike Joseph: The Interop block, the ‑‑
Leslie Nobile: It's included in the available inventory. It shows up on our website right now.
Mike Joseph: So that would immediately go down by one /8.
Leslie Nobile: Correct.
Mike Joseph: I see. Is that the same formula also used on the website counter?
John Curran: Yes. It's presently in inventory.
Leslie Nobile: Yes. And it shows up on the website every day. 4.95 /8 equivalents is what's available in the inventory right now, and that includes Interop.
Mike Joseph: But that's the metric essentially you're using for this?
John Curran: Yes. It does not include ‑‑ it does not include blocks reserved for policy, but it does include the Interop block because it's in the available space. Any other questions for Leslie?
Leslie Nobile: Thank you.
John Curran: Thank you, Leslie.
John Curran: Okay. Seeing as we have no questions, we'll skip over ‑‑ let's see. We have a question. We most certainly have to have open mic. So we're going to open the microphones for questions from the community. We usually do this at the end of each day. The first question on the table is ‑‑ do you want to state it, Marty, or do you want me to state it?
Martin Hannigan: Let me try this again. My question is: Will you provide us with prior notice before returning any addresses to the IANA?
John Curran: Okay. And I'm going to ask. Is ‑‑ the Board hasn't considered that. Would you request that we do that?
Scott Bradner: Marty, two different things. One is I think the underlying ‑‑ your underlying implied question in what you said earlier is you don't believe that there was consensus to return addresses expressed. So that's the first thing. Second is so let's assume that we'll talk ‑‑ I think talking about that thing ‑‑ that separately is probably a good thing to do, sure. The second question is, modulo that, are you asking for advanced notice for each individual chunk of address space or advanced notice for the concept of returning?
Martin Hannigan: I think at a higher level it would be more effective with regard to the concept, because that would pretty much apply to almost the entire inventory. I don't expect the organization to announce every time it's going to return a /20 to someone or to the IANA, if that would ever occur. But I do expect that the Board would establish a baseline with respect to what the community actually wants to do. We now have the transfer system. And, again, this is ‑‑ I'm going to switch to speaking for myself. Personally sending addresses back to the IANA and having them divided up and potentially go to regions that don't have immediate need is slightly distasteful. I think that putting them into the transfer system would put them to better use. I think these are the type of discussions that have not occurred.
I also think that at least in my computer tells me that a few folks in the room were surprised that the number on the website four /8s will immediately go to three, or at least I interpreted it that way, that John's saying that when the proposal is adopted by the Board that right off the bat 45 /8s going back. When I said ‑‑
Scott Bradner: 45?
Martin Hannigan: Is it 45? Oh, 45. Sorry.
John Curran: It's 254 out of 256 /16s.
Scott Bradner: /16s, not /8s.
Martin Hannigan: Okay. My mistake. Thank you for the correction. There is a 45 /8 of which there is a significant chunk of it sitting there. That's a different thing. It seems to me that the base question is the one that you asked for first, because John just did give you notice that he would be proposing to the Board to return. So I think you have your notice. So having the discussion on whether that is what the community wants, addresses to be returned or provided to the IANA, is the fundamental question you're asking.
John Curran: Can I ask one question, Marty? There were several versions of a return and reallocate proposal, global policy.
Martin Hannigan: Proposal combat.
John Curran: You were in some of them. And the earlier version specifically mandated that return. And the ARIN region noted an objection, particularly because there's no way to know what the policies in the other regions would be, and, as you noted, we could have address space we're required to return that's going out through policies that aren't at all RFC 2015 or need basis.
And so we noted we would designate address blocks for return. That was the last change and the third version in the 2011 version, which is before ICANN right now. I know we stated that we will designate the ones to be returned, which means if global policies change, we have the ability not to return anything.
But I guess as the one who would be writing the recommendation probably in five or six weeks, my question is I believe any address space that goes to the IANA and is going to be reissued in all the RIRs is going to get issued out on needs‑based policy today. Are you aware of any RIR that's dropped that which would give us pause on returning?
Martin Hannigan: I don't think that's relevant to the question I asked and the discussion that should be had with respect to do we as a community want to return addresses to the IANA or not, and I'd prefer to leave it at that. Thank you.
John Curran: Okay. I will live with the information I have. People who want to speak on the matter should we be returning addresses to the IANA today, the microphones are open. Sorry. The microphones are open today on the question of whether or not we should be returning addresses returned to ARIN to the IANA. Center rear mic.
Scott Bradner: After the global policy is adopted.
John Curran: After the global policy is adopted. It's very useful to have Mr. Bradner to help keep me in line. Yes. Rear mic.
Kevin Blumberg: Kevin Blumberg, ARIN AC and The Wire, speaking on my behalf, hoping to get some corrections from Mr. Bradner. Looking forward to it. My understanding was that the text was written in such a way that it was may return, and to me the key is that it should be a default of not unless there is community consensus about returning. The only time that I really feel strongly that it should be used is in a situation where an organization wants to return space, gift it back, and specifically stated that the only way they're doing it is if it goes back into the main pool. The IANA pool.
To me that is ‑‑ ARIN is acting as a vehicle for that original legacy space as an example. And that should be the only time today ‑‑ this might change in a couple of years; might change in a couple of months ‑‑ but right now that's my feeling of it. That's how I understood, was that it would default to not returning until the community was compelled to.
John Curran: Thank you. Center microphone.
Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC, speaking as myself, a member of the community. My understanding and my intent in the various debates around the global policy was to give ARIN the out if other RIRs didn't have needs basis or if the IANA policy, the global policy that got adopted, didn't include a needs basis for distribution, which some of the earlier ones didn't. They just sort of took whatever came in and divided it up amongst everybody and were done.
So we got all of that. We got the other RIRs to stay on Board with needs basis as near as I can tell. We got the IANA to accept the idea of distributing on needs basis. That was adopted by the other RIRs and the global policy that's now before the ICANN Board. I think it would be at this point disingenuous not to return space when we're sitting on pretty much the largest free pool on the planet and we are by far not the largest region left on the planet or the one with most unconnected users yet to be connected to the Internet.
I just can't fathom a reason not to return the space at this point, other than pure, unadulterated, disingenuous greed, and I think that's a poor example to set before the world.
John Curran: Thank you. Center rear mic.
Jason Schiller: Jason Schiller, Google, NRO NC. I wanted to point out some historical discussions about this very topic. Last fall when we were discussing ARIN Policy Proposal 2011‑9, the Global Policy for Post Exhaustion IPv4 Allocation Mechanisms by the IANA, I said something to the effect of “but I also want to make sure that if we do pass a global policy for IANA to distribute resources that it's one that we can comfortably get behind and return space. I don't want this to be an empty policy that the community is not comfortable recommending the return of space.” There was a lengthy discussion about that, and then, subsequently, at the open microphone, the topic of should we actually return space to the IANA was also discussed. So if you want to go back and look at the transcript from the last meeting, you should probably review that.
John Curran: Thank you. Rear left mic. Your left to me.
Marla Azinger: Okay. Marla Azinger, Frontier Communications. I just need clarification, because it's probably written somewhere and I just don't know where it is or missed it. What is the recipe for when ARIN would decide to actually give IANA space back?
John Curran: When the global policy is adopted by ICANN, then we have ability to return space that wouldn't be stranded. We have a policy that says until adoption of a global policy we shall hold it in the available queue. So sometime in about five weeks the option to return space becomes available to ARIN.
Marla Azinger: That doesn't answer the question.
John Curran: I'm sorry, I misunderstood.
Marla Azinger: If all passed, how are you deciding what address space you're returning?
John Curran: Prior to the policy that said hold all space in the region until a global policy, it was our intention to return all the space that was returned into ARIN. That has been our position historically to return space. We have done that with several address, very large address blocks.
Marla Azinger: Okay. I would venture to guess that maybe there's a basis for opinions having changed since the previous discussions have occurred, if that is how the decisions are going to be made, especially when there was policy passed in the ARIN region that said you can't put several different aggregates together in order to fulfill someone's IP request, because, you know what, it doesn't matter if it's one company or ten, you know, announcing those ten different aggregates. It's still the same announcements. There's policy out there that doesn't make a whole heck of a lot of sense, and if you're telling me you're handing back a /, oh, let's say just even a /14 to IANA and I need that and you're telling me you won't give me all these other aggregates that would equal that, I don't agree with that.
John Curran: Good to know.
Scott Bradner: I think, John, you need to be clear, clearer than you have been, that your intent is to recommend to the Board to return addresses when the global policy is adopted by ICANN.
John Curran: Right.
Scott Bradner: If that's your intent, you should say that's what your intent is.
John Curran: That's my intent. It matches ARIN's existing practices. Now, center front mic.
David Farmer: David Farmer, University of Minnesota, ARIN AC. I'm not going to repeat everything that Jason said, but Jason did bring it up in Philadelphia, there was a discussion. I think it's disingenuous ‑‑ while you may argue whether there was a consensus at Philadelphia, my review of the transcript, there was not a consensus against it. So I would suggest people look at it. I suggest we should be returning address space. I agree with Owen, it would be disingenuous not to.
John Curran: Okay. Center rear.
Michael Sinatra: Michael Sinatra, ESnet, and speaking entirely for myself, and, as I like to say, I'm not even sure I agree with the stuff I say. But one possibility or one standard we might want to discuss for returning address space to IANA is that if it came from IANA, then it should go back to IANA, which means that legacy space that came before the ARIN formation should in this model go back to IANA. I'm not sure whether I agree with that model or not, but that might be one place, one thing we could discuss.
John Curran: I just want to note that ARIN's the successor registry, so space issued by NSI or GSI that was returned to InterNIC or space issued by InterNIC to ARIN are all a chain of registries serving the same function. We actually don't distinguish in our policies between address space at this point. So if you ask ‑‑ address space that was issued by ARIN, I will tell you that it was issued by ARIN or its direct predecessors in all cases.
Michael Sinatra: So would it make sense to make a distinction between legacy space and non-legacy space? I don't know.
John Curran: I don't know. I just want to be clear. That's a valid question. We don't distinguish currently in policies.
Michael Sinatra: Something to throw out, then.
John Curran: Yes. Center front.
Andrew Dul: Andrew Dul, Cascadeo, speaking for myself. The policy to return space assumes that we'll be returning space obviously. How much space are you planning to recommend to the Board to return to IANA? We've heard the almost /8 from Interop, but how much other space is in this pool that you're considering recommending to return?
John Curran: 254 /16s, obviously, which is the Interop piece, and almost an entire /8. And then, Leslie, if I say a total of a /20 is the aggregate of ‑‑ that little piece is a lot less, I guess is what I'm saying.
Leslie Nobile: How much do we have that's been returned that we're holding on to?
John Curran: Correct. Does it amount to another /16?
Leslie Nobile: At least, yes.
John Curran: It does. Can you look up the number for us?
Leslie Nobile: Easier said than done, but I'll try.
John Curran: We will endeavor over the next day or so to make that. Andrew, to answer your question, it might be a little larger than I thought. We do intend to take the space that's been returned to us and return it to the IANA. That's what I will be recommending. And if there's ‑‑
Scott Bradner: That's what you're going to recommend to the Board; it's not that you're intending to actually return it.
John Curran: I don't do anything. I write stuff for them and you and you guys approve it and I do it. But, yeah, that's ‑‑ what he said.
Center rear mic.
Bill Sandiford: Bill Sandiford, ARIN AC. I have a question that relates to my thought process on this, but I'm not sure of the answer, and that is: Is there a responsibility as a community in ARIN to the member organizations inside the ARIN region, or is it our responsibility as a global Internet community? Is there anything in ARIN's incorporation documents or whatnot that states who we're acting on behalf of as far as the community? Because my thought would be if it says that we're acting on behalf of our people in our own region that we would be foolish to return anything. That being said, if it says we're responsible to everybody globally, then we should be returning space.
John Curran: ARIN's articles of incorporation are on the website under Corporate Documents. And if you go and look, you'll find the articles of incorporation have a vast scope in terms of our responsibilities. They could be read to encompass the entire Internet community. So we have freedom of action here, is what the ‑‑ you folks on the Board said is the mission that really decides it.
Scott Leibrand: Remote participant comment.
John Curran: I was actually looking for the other Scott, and then I'll get you.
Scott Bradner: I've been told to read. The articles do say in the seventh section, No. 4: To manage and help conserve scarce Internet protocol resources, and to educate Internet protocol users on how to efficiently utilize these scarce resources as a service to the entire Internet community.
John Curran: So it's pretty large scope. Does that answer your question?
Bill Sandiford: Certainly.
John Curran: Scott, remote participant.
Scott Leibrand: This is a remote participant comment from Scott Morizot from the IRS. He asks: What if, for example, a legacy address holder returned addresses with the proviso that they went back to the IANA rather than the transfer market? There are groups that might prefer needs‑based issuance over the transfer market. He says, “It's not that we're anxious to return legacy space right now, but I'm reasonably certain we aren't interested in placing addresses onto the transfer market. Of course at some point we'll hopefully have IPv6 sufficiently implemented so that we can return all IPv4 to IANA. “
John Curran: And to point out, there actually is for an organization that has an allocation of /8 in size, it ‑‑ there is the option of going directly back to the IANA, because they manage the registry at that level, and returning it. So that is an opportunity. But the point is taken.
Microphones remain open. I will note we have ‑‑ Leslie, you have an answer? Go ahead. Point of information.
Leslie Nobile: I have an answer, yes. We currently have 2.449 /16s that have been returned to us that we're holding in our bucket.
John Curran: It would be 254 from Interop and then 2.449 equivalent /16s as well. /8 plus noise. Okay. Everyone's queued at the back, but that's good, it makes it easy. Louie, at either mic.
Louie Lee: I'll come up to this one. Louie Lee, ASO Address Council chair. I just wanted to make a correction to my earlier comment. I sent my message to ICANN on March 13th. It was acknowledge received on the 14th, so that was roughly five weeks ago. So adoption could be three weeks or sooner if the ICANN Board adopts it.
John Curran: That's correct. Thank you. Marty, rear microphone.
Martin Hannigan: There seems to be some diversity in opinion with respect to returning addresses to the IANA. And I think I'm still unclear as to what the process is going to be going forward. So, for example, I know that most of the Board ‑‑ most if not all of the Board members are sitting in the room, but are we going to have some more formal discussion on whether the community wants to return addresses aside from the discussion in this room? Should we do an ASCP, should we discuss it on the Mailing List, et cetera, et cetera? I think this is something that should be discussed far and wide.
John Curran: What's your recommendation?
Martin Hannigan: All of the above. What's your recommendation?
John Curran: I'm not raising it. I was going to tell the Board we should return. But if you want to have a communication or a consultation, I'm just wondering sort of which one you're recommending.
Martin Hannigan: I don't know. What would the Board prefer? Because they're the ultimate target of the opinions, I guess.
John Curran: Of course this is open to the Board. If anyone wants to comment regarding how you intend to handle this other than receiving my recommendation and acting. Scott, you want to...
Scott Bradner: I would like to know what the community opinion is. We've heard some of it here. It's not unanimous one way or the other, but we haven't done a show of hands. And I'm not asking for one right at the moment. There's another Board member speaking, who are going to speak, too. I certainly got from previous discussions and the way that the previous ‑‑ the proposal, policy proposal we just talked about was worded was explicit ‑‑ implicit that there was support for returning. Otherwise we would have just said don't return rather than don't return until there's a global policy.
So my belief from previous discussions is that this is support for dealing with, as Paul just mentioned, the entire Internet community. But I would like to see a discussion on the Mailing List, and I would not want to precipitously move after the president's recommendation as an individual Board member, but I don't think we should drag it out for another meeting.
John Curran: Rear microphone, center rear.
Paul Vixie: I'm just jumping the queue to ‑‑ you asked what the Board might think. I don't feel like I know how I would react to your suggestion to the Board that things be returned. As Heather said, there's been a lot of movement, both directions, since Philly and even before Philly. So I would be in favor of either an MSCP or some kind of a well‑directed Mailing List communication. I'm not so much looking for a show of hands or a hum or whatever, but I'd like to see the issues aired now as things are today.
John Curran: Okay. We have a remote participant. Go ahead.
Scott Leibrand: Just me.
John Curran: Scott, go ahead.
Scott Leibrand: I would like to point out that there were slides presented earlier today by Leslie that showed the number of /8s that each RIR is holding. We're sitting at the very top of that list with 4.98; next after that is AFRINIC; next after that is LACNIC with 3.73. And she also pointed out LACNIC has given out more space this year than we have. So I would speak in favor of returning the approximately /8s worth of space we have left and having that distributed. I think that will get the space into use on the Internet faster than it is being used today and solve real needs of real users on the Internet as opposed to leaving it unused in a pool.
John Curran: Did you want to respond directly to that? So, Paul.
Paul Wilson: Paul Wilson from APNIC. I just wanted to comment and respond to a couple of things said earlier. I don't know who said it, but one mentioned distinction between legacy addresses as those that were allocated in common perception by a central registry into what are now RIR regions, but prior to the RIRs, the distinction between that central registry space and the RIR space. And, in fact, talking ‑‑ referring to what Leslie presented earlier, the NRO has collectively made that distinction traditionally over many years. We've documented in that donut pie chart that the central registry accounts for 91 /8s, and the RIRs collectively together have 130 /8s. So we have distinction already established historically between the central registry and the current RIRs, and in fact that's something that's come up in conversations many times over the years.
I mean, I've been asked why ‑‑ more times than I can count I've been asked why America has received so much address space. This is quoting. It's a question that I've heard and been asked. America has received so much space and this is unfair, et cetera, et cetera. What my response traditionally to that has been: That the historical address space that was prior to the establishment of the RIRs was never allocated to America, it was never allocated to ARIN, because ARIN didn't exist there; it was allocated to organizations that happen to be wherever they happen to be, and it's quite true historically, given the way the Internet developed, that most of that address space happened to be allocated to organizations in America.
And I had a perception of an understanding of a general agreement that was as ‑‑ as was referred to before by the guy who commented that ‑‑ that that address space having been returned ‑‑ having been allocated, not to the RIR, but to the organization, if it was no longer needed would go back not to the RIR but to the IANA where it came from. That was a common perception. Now, if that is under question or no longer the case, then that's something that has some global impact. And, in fact, the RIRs have been engaged in some discussion about this at the Board level in the past.
And I think it's not yet resolved as a consensus of the RIRs. But I would ask that the ARIN community consider what the IPv4 pie chart would look like if in effect the ARIN's autonomy to take the legacy address space, hold it, and do with it what you see fit, that effectively represents a division of the 91 central registry blocks to RIRs which will assert ownership over them.
Now, what that looks like is either 91 blocks divided up with 48 of them being held by ARIN, bringing ARIN's total to 84 blocks out of the entire IPv4 pool, or in another case if ARIN is asserting its authority over the 91 blocks as the successor registry, then, in fact, even though those blocks ‑‑ some of those blocks actually have been allocated outside the ARIN region, it would give ARIN 91 out of the 91 central registry blocks and create an even bigger disparity in that pie chart.
And I would ask you whatever the decision is that you wish to make as a community, I ask you to think about the appearance and what that looks like compared with a history of discussions that's been more about how the Internet evolved and how we got to where we are and why, in fact, the addresses that happen to be used in the US ended up in the US in the first place. And those two discussions lead to different viewpoints, and you'll be picking one or other of those viewpoints in making this decision. Thanks.
John Curran: Okay. Interesting comment. Yes?
Scott Bradner: Question for you first. Do we have an open mic session tomorrow? Is that right?
John Curran: We have an open mic session tomorrow. We'll be closing this shortly.
Scott Bradner: Maybe we can explicitly dedicate that session to this topic.
John Curran: If that's desirable.
Scott Bradner: And ‑‑
Scott Bradner: And so we have some time to think about it and talk about it. We'll have plenty of time waiting for the bus and waiting for the trolley and things and the gondolas and things like that and time to get it lubricated tonight. So let's ‑‑ I would suggest that we actually stop the discussion now and move it to tomorrow. I do want to say one thing that's sort of in line with what Paul said. Slightly different piece of it. There is a session coming up in December in Dubai where the ITU is trying to restate the treaties under which it operates. For ARIN to decide to be selfish, and I think that's the right word to use, to keep addresses that were returned within the ARIN space, while it's certainly to the benefit of ARIN to do that short term, it hands those who would say that the RIR community meets external supervision a very big stick. So I would like you to keep that in mind and I suggest we pick this up tomorrow.
John Curran: We are time constrained, and we actually do have to have someone come up and speak before we adjourn. If anyone cannot wait until tomorrow, please remain at the mics. If you can resume this tomorrow, I ask you sit down. We're going to continue this topic at that time. If you're leaving, and you can't wait, then stand at the mics, but the mics are closed and I want to drain them of anyone who can't wait until tomorrow's topic ‑‑ open microphone on this topic. Look at these people who have to go. Okay. Go ahead, Bill, quickly.
Bill Sandiford: Quick comment with regard to Scott's bringing up of Leslie's numbers from her slides. I think it's a slippery slope to assume that just because we have the most numbers of addresses in our free pool and are allocating them at the slowest rate is a justified factor for giving resources back. There could be very valid reasons why we have the most and very valid reasons why we're giving them out slower. We may have more stringent policies, et cetera, and it shouldn't necessarily be used as a factor for this discussion.
Jason Schiller: Jason Schiller, Google, NRO NC. I just wanted to beg the Board to consider this topic and what sort of advice they would like from the community on the returning of space to IANA and for them to bring some well‑formed questions and have a well‑formed idea of what sort of feedback they want from this community.
John Curran: Okay. Left rear mic.
Marla Azinger: I have four I'm holding. The only one I'm not is because there's a remote participant that may not be back tomorrow. So the IRS person that mentioned they were concerned about handing back address space directly to ARIN and they would prefer to say no, it's going to IANA because they didn't want it going on the transfer market, I just want to make sure everybody understands if you hand address space back to ARIN, it doesn't mean it's going on the transfer market; that means they're actually going to hand it out to somebody that sent in an IP request.
John Curran: Right.
Marla Azinger: I wanted to make sure that was clear, because that was very misleading.
John Curran: Okay. Thank you. And center rear mic, Louie, last comment.
Louie Lee: Okay. I want people to consider tonight the possibility that if we spread out the pain of IPv4/IPv6 transition by spreading out addresses and having more even use around the Net and we all end up with no IPv4 space all at the same time, we can have one Internet.
John Curran: Good point.
The open microphone is closed. Thank you very much.
John Curran: We have a wonderful social tonight, and I'd like to have a few words from the sponsor of this evening's social come up. Thank you, first, for our connectivity, Telus.
John Curran: Tonight's social by .CA, our friends at CIRA. It's on Grouse Mountain. And I believe we have ‑‑ do we have someone? Come on up. Thank you.
Byron Holland: Thank you very much. It's great to have all of you here. My favorite speeches are a short one, and I promise this will be short. My name is Byron Holland and I run CIRA, the Canadian Internet Registry Authority. We do .CA. I'm no stranger to the multistakeholder model, but, generally speaking, my beat is more in the ICANN/IGF fold. And it's been really interesting to watch this from the back of the room. And I just want to say there's a lot of really good, honest, meaningful dialogue that takes place. And certainly from the CIRA world, where we do the multistakeholder thing, I'm definitely taking notes because there's a lot of great dialogue here and we'll be taking it back to the CIRA world as well.
That said, Grouse Mountain is a beautiful place. For those who haven't had the benefit of being here before, if you can do the snowshoe tour, which I think is on there, I'd highly recommend it. I think we have a clear night tonight. It will be an incredible view of the city from the alpines overlooking the water. Highly recommend it if you can do it. And beer’s on me. So have a great night.
John Curran: Thank you, Byron. We should have a great social tonight. And a recap. We'll start tomorrow at 8:00 a.m., and the meeting starts at 9:00. 8:00 a.m. for breakfast, meeting at 9:00. Agenda is in your folder. Tonight's social, buses begin leaving at 5:35. Last bus leaves at 6:10. Move briskly. Thank you.
[Meeting adjourned at 5:05 p.m.]