ARIN 31 Public Policy Meeting Draft Transcript - 22 April 2013 [Archived]

Opening and Announcements

John Curran: Good morning. I’d like to welcome everyone to ARIN 31, our Barbados meeting. Although it wasn’t always sunny, it is a beautiful environment to be in. And I thank you all for taking the trouble to be here.

We have a number of remote participants. I’d like to thank them all as well.myself. Vint Cerf could not be here, but he sends his regards. Tim Denton, our Chairman, is here. Aaron Hughes is here hiding in the room. Paul Vixie also sends his regards. We spoke to him this morning. And Bill Woodcock is here, Board member.

Advisory Council. We have the entire Advisory Council here. If you’re a member of the ARIN Advisory Council, stand up. These folks were elected to help you work on policy, to manage the Policy Development Process. They’re led by John Sweeting. John, raise your hand. And Vice Chair Dan Alexander. Dan, where are you? Thank you.

Number Council, the NRO Number Council. We elect three people ‑‑ actually we have three people from the region who are selected by this, two elected by the community, one appointed. And that includes Ron da Silva, Louie Lee, and Jason Schiller. Louie is the chair actually elected of the whole Number Council. There’s three from every RIR, 15 total, Louie serves as the chair.

And the Number Council works on global policy matters, so when we have a policy that’s unified between the regions, they’re the ones that do the work to assess that. They’re also a point of contact for the ICANN organization for coordination of number policy issues.

Our RIR colleagues. We have a number of RIR colleagues present. AFRINIC, Adiel and Mark. Yes? Somewhere. LACNIC, Juan and Arturo. Yes? RIPE, Axel, Sam, Andrew, Dmitry, and Andrea. Yes, yes, yes. And Philip Smith from APNIC over in the corner. Thank you. Thank you to our colleagues for being here.

The ARIN management team is here. Myself, president and CEO; Nate Davis, our chief operating officer; Cathy Handley, executive director of government affairs; Bob Stratton, our CFO, could not be here; Susan Hamlin, who runs our able Communications team; Mark Kosters is here; Mary K. Lee, who handles HR and Administration; and Leslie Nobile, who runs the registration help desk.

Okay. Fellowship Program. We have three ARIN 31 Fellowship recipients. Leah Ungstad. Leah? Yes. Thank you. Frank Bulk. Thank you, Frank. And Devon Gayle. And these are recipients who come here in part of our Fellowship Program where we help people handle the costs to defray the expenses so they can participate, share the information back with their communities, bring new perspectives.

Each of them also has an AC member you can see, Cathy, Rob, and Owen. Thank you for volunteering, our AC mentors, for the Fellowship recipients. First timers breakfast attendees. For those here for the first time, there was a breakfast meeting and folks learned about ARIN and some of the terminology we used. We have a bit of terminology. And we’re going to ‑‑ actually, for those who attended the first timers breakfast, we’re going to draw for the gift certificate that we do for the first timers breakfast.

So I have all of their surveys here, and I’ll ask someone in the community to come up. Louie, come on up. Louie will draw out of our drawing bin the winner. Thank you, Louie. The winner is Amy Sansbury. You’re the winner of a certificate, first timers certificate. It’s electronic. We’ll send it to you. We’ll send it to you. Thank you. Very good.

I’d like to welcome our remote participants. Our remote participants have full participation in the meeting. They have access to the webcast so they can see us here. There’s a live transcript. They can download the meeting materials, the same materials that you have in your packets. They have chat rooms where they can actually post comments, just as if they were at the mic, through the virtual mic, and they can participate in the hands up, which is the show of support for a policy.

Attendance stats. We have nine folks from Canada, 57 registered from the United States here. We have 25 in the Caribbean. The reason we come down here is to help get participation from the region. 15 from outside the ARIN region, and 28 remote participants. So I’d like to welcome everyone regardless of where you are from the region.

I’d like to thank our sponsors. Our sponsor is Lime. Thank you, everyone.

(Applause.)

They provide our valuable network connectivity. And Google, our webcast sponsor.

(Applause.)

Okay. So some reminders. We moderate the discussion of Draft Policy so everyone can speak and everyone can be heard. This means that you want to clearly state your name, your affiliation each time you’re recognized at the microphone. There’s rules and courtesies in the program to make sure everyone has a chance to speak. Please comply with them.

Today’s agenda. We’ll start out with the Advisory Council On‑Docket Proposals Report where they talk about everything they’re working on. We’ll go to a Regional Policy Development Report, give an update on what’s happening in all the regions. The Internet Number Status Report talking about what’s available for resources, what allocations we’ve made. We’ll give the IPv6 IAB/IETF Activities Report, which is an update of the activities over there that might affect how we do policy.

We’ll hear the reports from our sister RIRs, global reports, AFRINIC, LACNIC, RIPE, and an IANA report. And then we’ll do the Policy Implementation Experience Report where we are responsible for telling you how we implemented the policies and note any issues or concerns that might be worth considering for policy development.

And we’ll have an open microphone. We also have on the agenda some policy discussions today where we’ll actually discuss the pros and cons of some of the policies that are being considered right now, and that includes ARIN‑2012‑2, the IPv6 Subsequent Allocations Utilization Requirement, and ARIN‑2013‑1, the Section 8 Transfer Enhancement.

Also after all that work we’ll have a little bit of fun. Tonight’s social is at Harbour Lights. Buses begin loading at 6:00 p.m. outside the ballroom, and the last bus leaves at 7:00 p.m. This is a wonderful little area out by Carlisle Bay. A lot of fun.

Please bring your name badge and your favorite tropical shirt. We have a tropical shirt contest going on. If you happen to have one, feel free to bring it. Return shuttles every 30 minutes, the final shuttle at 11:00. Harbour Lights will open up to the public after that. So if you do end up staying, just remember you have to find your way back here, taxi or similar.

At the head table. We have a head table. These people help me run the meeting. They also help pose questions and discussion. I have Scott Leibrand, Bill Woodcock, Paul Andersen, Dan Alexander, and Kevin ‑‑ I blank out every time ‑‑ Kevin Blumberg, obviously. So without further ado we’ll get started. The first item on the agenda is the AC On‑Docket Proposals Report, and that will be presented by the Advisory Council chair, John Sweeting.

AC On-Docket Proposals Report

John Sweeting: Good morning, everyone. Welcome to ARIN 31. I’m John Sweeting, Chair of the Advisory Council. Before I get started really into the one slide that I have, I’d like to welcome the two new members to the Advisory Council, John Springer and Milton Mueller. Thank you, guys, for volunteering and getting elected.

(Applause.)

John Sweeting: Look forward to really good things coming from you guys. And I’d like to take a second to recognize Chris Morrow, who is an outgoing member who did a great job the three years he was on the council.

(Applause.)

John Sweeting: So the AC On‑Docket Proposal Report looks a little bit different this time. What I’m really going to talk about is the AC lunch table topics. And two of those topics will be things that are on our docket today but are not brought here as Recommended Draft Policies, but they are ‑‑ we have moved them to Draft Policy.

So we’re going to have tables set up for people who would like to discuss those Draft Policies, the difference being that a Draft Policy, we cannot take it to last call from this meeting here. It will have to go to either a PPC, a Public Policy Consultation, or a Public Policy Meeting.

So some of the topics that were suggested and that we accepted to sponsor at the table talks are uses for the IANA reissued IPv4 remnants. Anyone interested in that, please look for that table. Non need‑based inter‑RIR transfers; hidden risk in the RPKI usage; ASN‑based IPv6 assignments; resource challenges faced by governments, ISPs, and end users in the Caribbean region; the two Draft Policies, 2013‑2, 3GPP Network IP Resource Policy, and 2013‑3, Tiny IPv6 Allocations for ISPs. And also reserved expansion space for IPv6 allocations.

That really concludes my presentation. So thank you all and look forward to talking to you throughout the meeting.

John Curran: Thank you, John.

(Applause.)

John Curran: Okay. Next up we have the Regional Policy Development Report, and that will be presented by Einar.

Regional PDP Report

Einar Bohlin: Good morning, everybody. My name is Einar Bohlin. I’m the Policy Analyst at ARIN. And as part of my job I’m subscribed to all the RIRs policy lists and I keep track of what policy proposals are introduced in those regions and what they discuss.

And at every ARIN meeting I take a snapshot to try to see what type of things are being discussed and how many, and I’ve been gathering that data for a few years now. So right now we are the right column in this chart. And as you can see as far as proposals on IPv4 space are concerned, we had a peak in 2011 which coincides with IANA running out and discussions about things like last /8 policies, transfers, global policies about what IANA would do with returns, and now we’re back to it looks like normal number of v4 proposals.

And we still have proposals about IPv6 and directory services and a couple of other categories. So we have two Recommended Draft Policies on the agenda today, and two Draft Policies tomorrow, and all of these policy proposals are unique to the ARIN region. There aren’t yet discussions about these types of things in the other RIRs.

Here’s some highlights of things going on outside our region. Later there will be reports from some of our colleagues at the other RIRs, and they usually tell us what ‑‑ they tell us everything that’s under discussion, what’s recently been implemented and perhaps even abandoned. But these are just a couple of highlights from the current discussions.

So as you probably know, ARIN and APNIC have inter‑RIR IPv4 transfer policies, and that topic is being discussed via proposals at the other three RIRs. And there’s a proposal in the RIPE region, which is I think is titled something like post depletion reality check. It’s a proposal. Since RIPE has exhausted their regular v4 space and is issuing from ‑‑ call it an austerity pool, there’s been a suggestion to change their regular v4 policy space policy.

And regarding v6 proposals, there are a couple of proposals in the LACNIC region which essentially make it ‑‑ well, one would be similar to what ARIN has in place which would allow the LACNIC region ISPs to determine the prefix sizes for their customers, not just fixed on /48 or what they currently have, and another proposal to make it easier to get large blocks of v6 space.

So the discussions at the other RIRs on their policy lists are very similar to the discussions at ARIN, and the criteria is the same for participation. These are open lists, anyone can participate, and some of the folks in our region participate on their list and some of those people participate on ours, and it’s good to get feedback from as many people as possible.

Here are some links to the sites where you can see exactly what’s under discussion at the other regions. Every RIR has a page with all of the policy proposals that are under discussion and whatever various state they happen to be.

And there’s also a link here to an NRO document, the Number Resource Organization. And this is a document that has all of the basic v4, v6, and ASN and transfer policies in one single document. So it makes it easy to compare things. If you want to find out do all of the RIRs have a transfer policy or an inter‑RIR transfer policy, you can go to this document and see at a high level whether they do or not and basically what kind of policy it is. But, of course, the authoritative policy, if you need that, you have to go to the RIR itself, if you’re doing a request or something like that. And I think that’s it for me.

John Curran: Any questions for Einar?

Einar Bohlin: There’s a question. Yes. Assistance is coming.

John Sweeting: John Sweeting with the ARIN Advisory Council. Einar, we had a question in the first timers breakfast this morning about historical proposal policy activity within just ARIN. So I see you do that for all the regions combined. Is there a way you can pull it out and let Susan maybe present that at future first timer breakfasts?

Einar Bohlin: I’m not sure I understand the question. Do you want to know an overview of what’s happened at ARIN, number of proposals?

John Sweeting: The numbers, yeah. The numbers. How many.

Einar Bohlin: Like how many proposals, how many draft policies ‑‑

John Sweeting: Annually.

Einar Bohlin: How many have been abandoned ‑‑

John Sweeting: The same way you had it up there for all five, but just for the ARIN region.

Einar Bohlin: Sure. I think we can do it pretty easily, incorporate it.

John Sweeting: We can pull it from the report that I do at the end, pull it from that.

Einar Bohlin: No more questions? One more, yes.

Milton Mueller: Milton Mueller, Advisory Council. In your discussion of RIPE, I just wasn’t clear. You talk about the post depletion policy. Is that the no‑needs assessment policy?

Einar Bohlin: Yes, that’s part of that proposal, to do away with a need requirement for moving v4 space in that region.

Milton Mueller: I thought it would be important to highlight the significance of that, that that is actually just past the initial proposal stage and has gone into the next phase for RIPE, and that has implications for ARIN because of the inter‑RIR transfer process. So I think people in ARIN should be very aware of what’s being proposed there, and it seems to have a lot of support in RIPE. So you might want to spend a little more time explaining what that’s about.

Einar Bohlin: Okay. The proposal that I mentioned at the RIPE region about changing their basic regular v4 policy set, one of the components would do away with the needs‑based requirement for issuing space to customers from RIPE, except that they can’t really do that because they have no regular v4 space left. It’s my understanding that any returns go into their austerity pool. So there’s a policy set for the austerity pool. They have no regular space. But there are policies about how ISPs give space to their customers and there are policies about how transfers are done.

And there would be ‑‑ with this proposal, if it was implemented, there wouldn’t be a need check for moving regular v4 space around. At the same time, in the RIPE region there’s an inter‑RIR transfer proposal, and it’s a condition at ARIN that such a proposal ‑‑ if RIPE and ARIN or RIPE and APNIC were to transfer space, it’s a condition that those RIRs have compatible needs‑based v4 policies.

So the RIPE region has to figure out if they move both of those proposals forward as is, even though they’d be establishing an inter‑RIR transfer policy, it wouldn’t be compatible with ARIN and APNIC because it wouldn’t be needs‑based, but that’s something that they have to decide for themselves.

John Curran: Now it’s working. Wonderful. Okay. It’s red for go, green for stop. So in particular the most important thing to realize is right now RIPE doesn’t have an inter‑RIR transfer policy. They’re discussing a proposal for one in parallel. If that inter‑RIR transfer policy is approved on its own, then there will be the ability to do inter‑RIR transfers between parties in the ARIN region and the RIPE region.

It does look to be compatible. It will be compatible right up until there’s a removal of a needs basis in the RIPE region by the second policy proposal being considered.

So if they add an inter‑RIR transfer policy, the transfers would be possible. If they remove needs basis, we’ll have a misalignment. As long as there’s a misalignment between the policy in this region and the policy in the RIPE region, inter‑RIR transfers won’t be possible until alignment is regained somehow.

So we’ve got two policy proposals, one to create a matching inter‑RIR policy, but one then to change and draw up needs assessment from their normal transfer procedures. And we have to watch both of them. Both will be discussed in Dublin in just a few weeks. Anything else for Einar? Thank you, Einar.

Einar Bohlin: Thank you.

(Applause.)

John Curran: Okay. Next up we have Leslie Nobile who will be doing the Internet Number Resource Status Report.

Internet Number Resource Status Report

Leslie Nobile: Okay. Good morning, everyone. So this is the Internet Number Resource Status Report. Basically this ‑‑ shows the status of IP Number Resources in all five of the RIRs. And this is updated quarterly. So this was just updated on March 31st. So it’s fairly fresh data.

The first slide shows the status of the IPv4 global address space pool. As you can see in the top right, we’ll start in the green section, 35 /8s are not available to IANA and the RIRs as they’re in use by the technical community. 91 /8s were issued prior to the establishment of the RIRs. We sort of lump it into this category called Central Registry, but that encompasses the early registries like the DoD NIC and SRI‑NIC and InterNIC, and all the legacy address space was issued at that point in time, basically early ’80s through early ’90s.

The RIRs have received 130 /8s from the IANA, and the pie below shows how that is broken up. APNIC has received 45 /8s; ARIN, 36; AFRINIC, five; LACNIC, nine; and the RIPE NCC, 35.

This shows the available IPv4 /8s in each of the RIR regions, starting on the left with AFRINIC in black. They have 3.78 /8s remaining.

APNIC in yellow has reached their last /8, and they have .88 remaining in their last /8. ARIN in blue has 2.49 /8s. We’re actually at 2.44 today, but this was a week ago. LACNIC in red has 2.62 /8s remaining. And RIPE NCC has also reached their last /8, and they have .97 remaining in their last /8.

This just shows ‑‑ it’s really cluttered, sorry, but since 1999 it shows the IP address space we’ve issued to our customers in total, and it basically shows the growth trends. And the thing to note is ‑‑ that I think is most notable is the APNIC space in yellow really, really increased between 2008 and 2011. They were issuing almost eight /8s at one point in 2010, so they really experienced a surge in growth.

This just shows the cumulative total of the amount of space we’ve all issued to each of our customers since 1999. This is ASN assignment, similar slide, just shows the growth trends.

Early on ARIN was issuing more ASNs than any RIR. At this point RIPE has taken over and they issue more than any other of the four RIRs.

This is just the cumulative totals. And 4‑byte. You can see the discrepancies in this slide because you can see that RIPE in green, LACNIC in red, and APNIC in yellow are all issuing 4‑byte ASNs, and you can’t even find ARIN or AFRINIC on this slide. There was a global policy that said basically you’re going to allocate ‑‑ you’re going to issue ASNs from one pool, don’t make any distinction between 2‑bytes and 4‑bytes so that we could encourage the use of 4‑bytes, just don’t make a distinction.

So the other three RIRs decided to issue 4‑byte ASNs by default, and it seems to be successful in their regions. AFRINIC and ARIN did try issuing 4‑byte ASNs, and almost every single one was returned. People were saying they could not use them, their vendors wouldn’t accept them, their upstreams wouldn’t accept them.

We decided to issue lowest to highest. So we’re issuing the 2‑bytes first in the hopes it allows the 4‑bytes to be acceptable at some point and we will eventually have to move over to issuing 4‑bytes.

And that’s just the cumulative totals. This is the global IPv6 address space pool. You can see the /0 in gray. A /3 has been carved out for global unicast. There’s 512 /12s in that space. So we’re just starting to tap into that. Only six have been used, six /12s, five issued to the RIRs under global policy in 2006.

And there’s sort of a miscellaneous /12 that’s bits and pieces used for documentation. Early on, the RIRs were issued /23s by IANA, before that global policy. So a couple of those 23s reside in that miscellaneous /12.

This is the IPv6 allocations to our ISP customers. And the most notable thing here is that IPv6 is really taking off in the RIPE region. They issue more space than any of the other four RIRs. It is growing in all the regions. But RIPE is really zooming.

And, again, cumulative totals of the total number of allocations made to our ISP customers. Here’s IPv6 assignments to our end‑user customers. And RIPE and ARIN issue more end‑user IPv6 assignments than the other three RIRs do. There are the cumulative totals. And we decided to track what the percentage is of our members who have both IPv4 and IPv6. And we’ve been tracking it steadily to see how much it will increase.

And it is increasing in most of the regions. It’s a little stagnant in the ARIN region right now, quite honestly. AFRINIC in black, a little over 33 percent have both, almost 48 percent in APNIC in yellow have both. 37 percent have both v4 and v6 in the ARIN region. 51.5 percent in LACNIC have both, and 59.23 percent in the RIPE region have both v4 and v6. These are the links to the statistics and you can get these online if you’re interested. And that’s all I have.

(Applause.)

Owen DeLong: If you could go back to the percentage slide, two slides. Owen DeLong from the Advisory Council. Is that number of percentages or recipients?

Leslie Nobile: Percentage of numbers. It’s just numbers. In the ARIN region it would be ISP numbers.

Owen DeLong: It would be interesting to see how it compares to recipients.

Leslie Nobile: It would be more. It would be higher, I believe. We can do it next time. Okay great.

John Curran: I have a question. Could you go back to the ASN slide, the 2‑byte, 4‑byte? That one. Perfect. So I’m interested in information regarding use of 4‑byte ASNs or, in particular, inability to use 4‑byte ASNs. If anybody in the room has experienced a problem making use of a 4‑byte ASN, can you raise your hand? Okay. Do these problems still exist, to your knowledge? Are there operators who don’t accept 4‑byte ASNs?

Bob Evans: Hi, Bob Evans, Fiber Internet Center. Yeah, it’s a problem with a lot of routers, especially on peering networks. ISPs have a tendency to throw the smallest router, their secondary routers on peering fabric, and lots of these don’t have the code to use the 4‑byte ASNs.

Juniper is one of the ones where you have to put in some special thing that says the peer I’m peering with is only a 2‑byte ASN speaker. And you gotta hub the thing properly and everything else and then maybe it will take effect. But you keep dropping these sessions. It becomes very annoying, disturbs traffic. So the 4‑byte ASNs are pretty much useless on a lot of peering fabric.

John Curran: Okay.

Rob Seastrom: Rob Seastrom, ARIN Advisory Council, and I used to work for a TLD operator. And we ran into similar problems to what Bob discussed, also with the same brand of routers, where the version of code we wanted to run for particular functionality that had in other ways was unfortunately from 2009. They had added features that were deleterious to our cause in later versions, but the later versions also added 4‑byte ASNs, so we had a bit of a quandary there. The solution I think will mostly be taken care of by time, but I don’t think it’s all been taken care of yet.

John Curran: Okay. That’s useful information to know. I guess the question I would ask the community is: We are actually getting towards the run out of 2‑byte, and so is there any actions ARIN should be doing here to make it clear to folks that this is going to happen? All right. Something to think about. Thank you, Leslie.

Kevin Blumberg: Kevin Blumberg, ARIN AC. One of my other hats is working with an IX, an Internet exchange, and, yes, there are some technical issues. I think if you look at the RIPE region, those technical hurdles can in many cases be dealt with again over time especially. But what can’t be dealt with is peering policy and perception issues, and that’s something that is borne by humans, not by technology. And there is a stigmatism to 4‑byte ASs, especially with new entrance, and that’s not something that can be dealt with, like I said, by technology.

Louie Lee: Louie Lee, Equinix, chair of ASO Address Council. I want to know if as the ASNs are issued is there some little blurb material telling people about the 4‑byte ASNs and maybe that might be something we look at, then at that point they’ve already received their 2‑byte, so it might be a little too late for that particular request. I’m one of the few that actually comes back for more ASNs, so I don’t know if that’s even ‑‑

John Curran: We’re happy to do whatever the community wants here. But we need guidance, obviously.

Leslie Nobile: I believe our template has an option to take a 2‑byte or 4‑byte and no one requests 4‑byte ever.

John Curran: Thank you, Leslie. Next up we have Cathy Aronson, and she’ll be giving us the IPv6 IAB/IETF Activities report.

IPv6 IAB/IETF Activities Report

Cathy Aronson: Hi. So this covers two meetings. So it’s a little bigger than normal. And I just wanted to point out this slide. This is Grammy Award‑winning musician Rubén Rada. I’ll talk about him in a minute. I got to see him, so I was pretty excited.

Okay. So this is my little blurb. If you were at any of these meetings and I forgot anything, speak up, because there’s a lot of working groups and I can’t be everywhere at once. And I only talk about stuff I think is interesting. So if you found something else interesting, then let me know.

So something happened on the way. I was supposed to be at the ARIN meeting for a week, go home for a week, then go to the IETF, but R.S. had emergency gall bladder surgery and I ended up in Uruguay. So after the first few hours there and getting robbed, I got to see Rubén Rada and fireworks from the LACNIC offices.

And I wish we had as much pomp as they do. It was their tenth anniversary and no one else from ARIN could make it because of Hurricane Sandy. I got to go to award ceremonies and all kinds of cool stuff, and it was really great. And R.S. was okay so I didn’t have to feel bad, so it was pretty awesome. So that was pretty neat.

IETF is getting a lot more in tune with allergies. So for those who can’t necessarily tell, that’s a humongous bowl of nuts with a sign that says “may contain nuts,” which is great. You’ll see later in my presentation that that sign comes in really handy for a number of things. Anyway, I like this quote. Anyway, Sysco, Cisco. Okay.

So for those who don’t know, every Sunday since pretty much the beginning of time there’s a meeting before the IETF called the IEPG, the Internet Engineering Planning Group. And even people I know have been going to IETF for 100 years go: What’s that? Basically what it is is a bunch of network operators, and there’s some interesting presentations that happen.

And these are some of the ones that were there. A fellow from LACNIC talked about some NAT64 work he’s doing. And for those who don’t know about the RIPE Atlas Project, it’s really super cool and I want you to know that Wyoming is now on the map. We have a RIPE Atlas probe at our house. So you can see how there’s no traffic in Wyoming.

They gather ‑‑ they have these little probes. You can plug them in and they have network statistics from all over the world. It’s pretty neat. Let’s see. There was talk about IPv6 address scanning and how the myth of it all is that there’s this huge address space but actually it’s pretty deterministic about how networks choose what address space they’re using, so it’s actually not that hard to scan and discover what’s out there. Of course there are attacks where people scan all the address space, which is there is an RFC about that.

Let’s see. There’s a new RPKI Spider tool, which tracks RPKI information, which is of note. There’s some work with DNS rate limiting because there’s a lot of attacks going on in the DNS.
In IPv6 Maintenance Group, let’s see, there’s ‑‑ yeah, these are some of the things that are going on there. IPv6 options. There’s some problems with turning them on and off and getting traffic to go where you want it to go.

Oh. I love this. So at the technical plenary there was a keynote speaker about turning off the plain old telephone system. And those people clearly don’t live in rural America, because in rural America, like that’s all you got. So where I live we’re going to have POTS for a really long time, but they’re talking about the telephone system being put over the Internet, which is more and more what’s happening.

So, okay, remember we have these MAC addresses. They’re a finite resource, and they hand them out in really, really tiny blocks and really, really big blocks. Well, the guy came back and he gave a talk again, and he made a real specific point to say that that was really not at all like IP addresses, that they’re ‑‑ I don’t understand exactly why that wouldn’t be just like what we went through, but apparently I was told a number of times that it’s not the same because there’s no hierarchy in MAC addresses, but there’s hierarchy in IP numbers.

Anyway, some more on that. They’ve decided that instead of having 4,000 and ‑‑ what is it? ‑‑ 16 million sized blocks, now they’re going to have four different sized blocks: 4,000, a million, four million, and 16 million. So it’s like A, B, C, and D, I think. And they decided that what they’re going to do is disconnect the company identifier from the MAC address block. So you can just get a company identifier and then have all the rest of your stuff be local space.

So if you’re a hosting company and you’re reusing them, you’re not reusing global numbers, but still I still think it’s a lot like IP addresses. Maybe somebody can help me with that. But he presented like three times and he made a point every time of saying how it’s not like what we do. So, anyway, there’s that.

Okay. So they have ‑‑ every IETF now, the Internet Society puts on a panel, and their varying topics. And this one was about your Internet content, when you connect to the network, and maybe it didn’t end up being used as you intended it to be, and that kind of reminded me of that show Tosh.0 where people put up their videos and then they end up on TV and some guy is mocking them and saying nasty things about what they did in their video.

But it’s a whole push to come up with some kind of identity where when you publish anything on Facebook, or whatever, your identity goes with it that says, oh, I don’t want you to do, whatever, put it on TV, or whatever. So that was a pretty interesting panel.

And in the BEHAVE working group, there’s some work being done. Not a lot. Actually the working group is pretty much going away. So these are some of the things that they’re doing in there. Basically it’s the behavior of NAT and between v4 and v6. The working group that’s looking for a purpose, the IPv4 sunsetting working group, is ‑‑ they’re still hashing out what they’re doing, but some of the ‑‑ the first three bullets there are some of the things that they think are in their charter, but they overlap a lot with dynamic host configuration, because it’s really sort of a fine line between like when you’re trying to decide whether you do v4 or v6, and you kind of have to decide that to figure out how your host is configured.

The WIDE folks in Asia, they’re doing a lot of work with this v6 network they built, and then trying to do v4 over v6, which is pretty interesting, and they found that there’s problems with the DNS so they’ve come up with this whole scheme to suppress, to make sure v6‑only hosts only get a AAAA record because they get confused when they get an A record and then there’s timeouts and things take longer than they should.

So they have a whole paper that they worked on their DNS to make it so that if you’re only v6 you only get a AAAA record. It’s pretty interesting. Another working group that I follow, because I had spare time that session ‑‑ I’m not really sure I agree with this whole ‑‑ when it says me in the bullet, that’s really me, not the guy who gave the talk.

But I think that it’s like an arbitrary overlay to make it so that the hard routing stuff you don’t have to do anymore, kind of. Like there’s this big controller that miraculously makes BGP work and everything underneath that we all do. And I’m not really sure that that’s really going to go anywhere. But there’s a couple different models of how to do that, and so they talked about it in this.

There’s ForCES and then there’s Openview, and they’re trying to come up with an Internet exchange that is managed by one of these controllers, but it’s just sort of like a big route server. Anyway, in the transport area, there was a tutorial. It’s pretty interesting. And there’s a lot of issues right now in the transport area with buffer bloat.

I don’t know if you guys have followed that, but there’s some really interesting work being done about pathologies in the existing network and the size of the buffers being actually too big. We always thought that they could be ginormous, but they kind of can’t. And there was ‑‑ they still haven’t picked a transport area director. So there’s a bunch of arguments about the criteria for what a director should have, even though they should have picked it already.

Let’s see. These are some of the things going on in the OPS area. There’s links to all these drafts online. There’s a lot going on with the control and provisioning of wireless CAPWAP. Really catchy.

Let’s see. And Softwire, which is everything tunneling. You can tunnel anything in anything else, and there’s a million different ones. These are some of the things that are going on in Softwire. Competing proposals for the same thing. This was a really interesting talk in Internet area. It actually might turn out to be the real solution to multi‑homing, which we know has been broken since the dawn of time, but basically having these functional domains and then using that to solve multi‑homing.

And then in LISP, which I’ll talk about in a little while ‑‑ John and I had the honor of being there ‑‑ they’re talking about this v6 prefix to use for LISP, and I’ll talk about that some more in a little bit. So this was really interesting as well. And I’m trying to get my mind around whether this community should be involved in this. But Jake, who is a woman, who ran the SRI‑NIC forever, was there, which was a blast from the past.

And they’re looking at just all the Internet data and the history and how it’s all disappearing, like maybe there’s a manual but the code’s all disappearing from like all the old equipment and how do you gather all of that and keep repositories talking to each other so that you have ‑‑ you start keeping this history because it’s all electronic and it’s really easy for it to go away.

And of course there were the endless IETFers, so like we have a closetful of stuff that my wife really doesn’t like, so if you want it, you know, like ‑‑ so trying to get all of that history gathered together. And there’s a “who’s who” in the Internet world website where there’s a guy who has been gathering on his own data from the early days of the Internet and trying to archive it. So there’s a bunch of work going on in that area, which is pretty ‑‑ I think that we should maybe try to figure out how ARIN, the RIRs can fit into that. V6 ops.

This is a pretty good document. There’s an Enterprise v6 Deployment Guideline document that actually has some pretty useful info. I’ve sent it to some of our clients. There’s some other drafts about loopback addresses and IPv6 for cellular that are being discussed. Design choices is another interesting document. The guys from Blue Cross/Blue Shield were back trying to get their IPID, and they’re having a little bit more success. I used to have a category: The most unusual speaker at IETF, and it was Blue Cross/Blue Shield one time. I don’t know if you guys remember that.

And the operational guidelines for datacenters document is moving along as well, which is an interesting read. Okay. So there are two different drafts that weren’t on the agenda for IETF, but they’re of super relevance here, and I don’t know why they weren’t ‑‑ I didn’t see them there. The first one is this one. And we’re going to have a lunch table topic about this as well.

So come join me, it’s super exciting, where the IANA assigns a prefix, a v6 prefix, and then any entity that has an AS number can use their AS number, plug it into that and get a unique IPv6 /48. So basically you get your own unique /48, and your only interaction with a registry, like ARIN, is to get an AS number. And I’m not sure how I feel about that. But it is kind of interesting read. And everyone in this community should be aware of it, because it impacts what we do and how people get address space. So I don’t know if anybody has any comments about that.

The other draft that’s on the IETF docket is a rewrite of RFC 2050, like bringing it into the present. And basically instead of all the nitty‑gritty of how address space is assigned in the original RFC 2050, this is just, okay, here’s how we do it, here’s the registry system, here’s how it works, here’s who runs it, go look there, the policy’s bottom up. And everybody I think in this room should be aware of that document, and I’m not sure if we’ll be discussing that any more than just me presenting it.

John Curran: I wasn’t planning on having a topic specifically, but we know we have an RFC 2050, which is somewhat out of date and actually contains a snapshot of policy from 1997 in it. And while we revised the policy, people looking at RFC 2050 will find precise guidelines for how allocations and assignments should be made. So we thought we’d do an update that reflects the actual current status of the registry system, myself, David Conrad, Russ Housely, and another author in there somewhere.

Cathy Aronson: I didn’t put them on the slide, sorry.

John Curran: We all worked on it and it’s been submitted and being considered under the IETF. If you have comments, you definitely should read it and comment. But we just thought it was good to have a document that was a formal success of the 2050. A lot of people wanted to actually expire 2050 and have it simply be declared obsolete.

And the problem is that when you have documentation that references 2050 for its principles, or for the structure of the registry system, if we just expired it, it wouldn’t point to anything. So we figured it was best to have a linkage. So when someone goes to 2050, they say, oh, here’s the current version of that document. It is out there as an Internet Draft. I believe it’s going through the general area in last call.

Cathy Aronson: So there’s that. Some work going on in dynamic host configuration. I won’t go into all of these, but these are some of the drafts that are being discussed. Homenet wasn’t nearly as exciting as it normally is. But they’re working on ‑‑ I did like this quote, though, if you have a /56 of address space per home and each address is a sugar cube size, then that’s several feet deep of sugar cubes around the world. Grains of sand as sugar cubes is the new thing apparently.

But there’s a bunch of different work, drafts. Chris Grundemann presented one about like everything in your home needs to automatically configure and miraculously route and it’s going to be OSP off and it’s going to configure itself, and I guess we’ll see how that goes.

But you can talk to Chris about his draft, he’s here somewhere, for one of the proposals of how to make it all work. There’s some more drafts here. There’s some really awesome quotes. Triangle routing. I love that. Anyway, so WCIT. We talk about WCIT some here. And Sally Wentworth gave this talk which fascinated me because it was more from the, “oh, my gosh, there’s a whole bunch of treaty people and they’re all in a room and they’re deciding about the Internet. "

I can’t give her talk because it would be another hour, but the slides are at the link. And if you get a chance to watch the video of her, it’s a really interesting talk and a really interesting process that a lot of people here have been involved in. Some of her slides just made me giggle. So when they’re trying to decide the policy, the language, and they can’t decide on the words, they put all the things they can’t decide on in square brackets. So this whole thing, basically there’s like, what, five words that they can decide on, which can you imagine having a whole ‑‑ I don’t know. It just boggles my mind.

And I love this. This is Patrick. He decided that WCIT was in square brackets. Everybody’s not even laughing. I don’t understand. It’s really kind of funny. And here’s a couple of ‑‑ like I said, her presentation was really in depth and it was like an hour and a half. But here’s some of the things that were being discussed as being policy.

And so, anyway, if you’re interested at all, I’d recommend that you listen to her presentation. This was more just to get you to notice that maybe they’re deciding things that are important to you. Okay. So I don’t know if you can see this. But this is the LISP working group and it may contain nuts. And it did contain nuts. But we won’t say who took the picture or anything, because he didn’t want to be named.

So the EID block that I talked about before. So /16 out of a reserve /12. And there’s a big debate in the LISP working group about whether it would need to be globally routed or whether it wouldn’t need to be globally routed and some of them say, well, we don’t really need it to be globally routed. And they seem to not understand that if it is globally routed, then it has to come from a policy process at the RIRs in order for it to happen. It’s not a special purpose block, if it’s globally routed.

So we had some discussions with some of the guys there about that. And the one guy said, well, loopback addresses, we got those. And I’m like, yeah, but they’re not globally routed. So there’s a big hurdle, I think, to get over whether they really need the block to do LISP, whether it’s globally routed or not, and they’re still arguing about it. I don’t know if you have anything to add to that.

John Curran: So the linkage, for people who are interested in it, is there’s an agreement between the IETF in the form of the IAB and IESG with ICANN. It’s an MoU in RFC 2860, and it basically says that the IANA ‑‑ the tasks of doing registry management will be done by ICANN, the IETF agrees ICANN can do that, and for things like protocols and parameters that ICANN shall take its guidance from the IETF.

But for things like names, domain names and IP addresses, it’s recognized there may be other policy matters. To some extent ICANN spends 95 percent of its time working on DNS policy, and we do that little five percent which is IP address policy. So the MoU says for names and numbers those may have policy matters and do not come strictly from IETF guidance and that ICANN will have other ways of dealing with that.

It then carves back out of numbers, numbers that are assigned for specialized purposes and for experimental purposes. So if the IETF has an address block for multicast, that’s not per se an RIR matter, it’s an IETF matter. So the question comes up with, well, if LISP has a set of identifiers but they happen to come out of the IPv6 space, is that a technical matter or is that a policy matter?

And basically if it happens without affecting any of the operational community, it’s probably a technical matter. It’s completely reserved and it’s not affecting ‑‑ it’s not showing up in the Internet. Obviously if there’s a chance that these prefixes will be routed and show up in the operational Internet, then it’s quite possible that the ASO, the Address Supporting Organization, and the RIRs working together, that their communities might want to have a say in this.

So this was all discussed in the LISP group, and they’re still trying to find out whether or not they want a specialized technical reservation, which would be a set of IPv6 address spaces you’d never see on the Internet except as LISP IDs or whether or not these LISP blocks they want to issue are also general‑purpose IPv6 addresses. Once they decide, we’ll know whether this is entirely within the IETF or whether this also needs to go out to the RIRs. I hope that explains some of it.

Cathy Aronson: I did some reading after the meeting and their document is very specific that it’s a routed block in the draft. So even though they’re debating it, it specifically says it’s routed in the draft itself. So we’ll see what happens. Let’s see. Oh. The may contain nuts for this. Dino gave a really long presentation about doing v6 multicast over v4 with LISP. And it was just terrifying like that you could manage a network that I don’t even know. But it really, really does contain nuts in that working group. I think they should get some people in there that manage networks.

But, anyway, arbitrarily complex. That’s it. Let’s see. And that’s where I’m at. So does anyone have any questions, comments? Are you awake?

John Sweeting: John Sweeting, ARIN Advisory Council. Cathy, I want to thank you for the job you do for the AC for going to the meetings. Even putting this slide presentation together must have taken you hours.

Cathy Aronson: It takes four hours.

John Sweeting: It’s all volunteer work. So thank you.

Cathy Aronson: That’s an elk from my yard so you can be super jealous.

John Curran: I can attest to the fact that sitting through the slide presentation is much more pleasant than sitting through the corresponding meetings at the IETF.

Cathy Aronson: Oh, and just another thing. These are some links that are really interesting. If there’s something that interests you at the IETF that you want to hear about, and I have an extra session that isn’t IPv6 at that time, I’m happy to go and report back about it.

So sometimes I sneak into SDN or whatever because I don’t have anything that I have to go to. But if there’s something the community is interested in, I’m certainly happy to go and check out something else. So, anyway, thanks.

(Applause.)

John Curran: Thank you, Cathy.

ARIN-2012-2: IPv6 Subsequent Allocations Utilization Requirement

John Curran: We’re now going to start in the policy part of our meeting with a discussion of the first Draft Policy. And this is going to be ARIN‑2012‑2: IPv6 Subsequent Allocation Utilization Requirement.

This is a Recommended Draft Policy, meaning that the AC has found it to meet the principles of Internet resource policy and recommended it for adoption. That means it’s actually capable after this meeting, if it’s found to be supported, of being advanced to last call. People should know this is definitely on the track somewhere.

It originated with ARIN Proposition 159 in November 2011. The shepherds are Heather Schiller and Cathy Aronson. It was presented at ARIN XXIX, XXX, and at the Public Policy Consultation at NANOG 57.

As I said, it was found to meet the principles of Internet resource policy, has been recommended for adoption. It is online and in your Discussion Guide.

Summary. Allow an additional way for ISPs to receive a subsequent allocation, in particular ISPs who have allocated at least 90 percent of their space to serving sites, to qualify for an additional allocation as long as the block size allocated to each serving site is justified based on the number of customers at the larger single serving site.

So if you’re completely immersed in IPv6 policy, this reads perfectly logically. If you’re not, I guess what I’ll say is it is possible for someone to allocate their addresses in such a way that because of growth they run out of addresses but they’re unable to qualify under the current policy to get new ones. And this is to fix that situation.

Status at the other RIRs. No similar policy proposals or discussions. Issues or comments. The updated text in 6.5.3b adds consistency and clarity to the policy by allowing the block size for the subsequent allocation to be based on the same criteria used to determine the block size for the initial. The policy is clear and implementable as written.

Resource impact. Minimal. Can have this done in about three months. And it’s just updated guidelines and staff training. Does not create any significant legal issues during the legal assessment. And in terms of PPML discussion, it’s been very quiet. So that’s the introduction to Recommended Draft Policy 2012‑2. And I will now ask the shepherd to come up, this will be Heather Schiller, to give the AC report.

Heather Schiller: So I think, Einar might be able to tell me, that I have the policy that’s been on the docket the longest. It certainly seems that way. So hopefully third time’s a charm. And every time there’s been sort of support for the concept of being able to get additional address space for having run out of subnets but not having ‑‑ the problem has been ‑‑ the problem that people have been concerned about is the wording of the text.

So the line highlighted in bold is what’s changed. And, again, the idea is just that if you’ve gone through your v6 allocation and subnetted it out and you need additional subnets, that being able to use that as justification to get additional v6 space. So any questions? Comments? Does that mean that you like the text?

John Curran: At this point we’ll open up the microphones for discussion. Vice chair, Paul Andersen, will come up and moderate the discussion.

Paul Andersen: Central mic.

Cathy Aronson: I made it work. Cathy Aronson, ARIN Advisory Council. So since I’m the co‑shepherd, I’m going to ask this: There are at least two people physically in the room right now who have made comment in the past about this policy at the microphone, and I would like to know whether this text now makes them happy. I think that would be Aaron and Jason, at least. So maybe we could get those comments.

Paul Andersen: I see Jason approaching the mic here.

Jason Schiller: Jason Schiller, Google and ASO AC. I was going to stay quiet and let some other people talk first, but apparently that’s not going to happen. So one of our concerns was this conflict with 6.5.2.1(f). So the original IPv6 initial allocation policy basically states that a network who has no intention of having hierarchy can invent one level of hierarchy and use that to appropriately size how much space they should get.

Then the assumption was, when they would come back and the network was actually flat, that utilization would be judged based on the fact that it was a flat network. So they had to actually be out with only one serving site. But the concern was once they are considered out, when they ask for the next chunk of address space, could they then again reinvent this hierarchy which they never planned to roll out in order to properly size their next block. And I think the answer at the last meeting was no.

I suspect the answer is now yes, because the new text basically says must be consistent with the initial allocation policy, which states that this process can be done.

I’d just like to see clarification, am I reading this correctly, that, yes, if I had a flat network but I was really out as measured with a single serving site, could I come back with some pretend hierarchy that I don’t plan to implement in order to correctly size my next block?

Paul Andersen: Can I ask John and then Heather to respond?

John Curran: The short answer: Yes. This text says you may continue based on the criteria specified in 6.2 ‑‑ 6.5.2.

Heather Schiller: If you originally ‑‑ if in your original allocation request had a single ‑‑ had a flat network with a single serving site, then you’re more likely to qualify earlier under one of the other criteria of 75 percent or the other 90 percent in a single serving site than needing this addition. If you have a single serving site.

Jason Schiller: Just to be clear, the concern is not about judging when that flat network is out; the concern is about once it is deemed that that network is out, how much space can they get in their next take from the well. And at least for the initial allocation process, you could take more than ‑‑ if you invented a level of hierarchy, you could actually qualify for more space than if it was just assumed as a flat network as you intended to deploy it.

Heather Schiller: But this policy has nothing to do with that. So this policy doesn’t say anything about the size of the allocation you get for a second allocation. It just gives criteria under which ARIN can say you get more or not.

Jason Schiller: Except it does change the definition of serving site, which is used by both the initial allocation and subsequent allocation.

Paul Andersen: My understanding is there is no change to Section 2.14. I actually asked about that earlier because ‑‑ my understanding ‑‑ because I was confused, too, why it was in the text then. My understanding is 2.14 is out as stated today in the NRPM.

Jason Schiller: Right. So that conflict has been removed as far as I can tell.

Paul Andersen: So based on that, Mr. Schiller, would you be supportive of that text?

Jason Schiller: We had two concerns. Certainly the first concern I believe has been adequately addressed. I’d like to sit down and hear some more discussion before I bring up the second concern.

Paul Andersen: So noted. Last chance to approach. Hoping to hear more discussion.

John Curran: It would be good if anyone has concerns about the policy proposal to approach a microphone since the AC needs that to do their job.

Paul Andersen: Even if you’re in support that could be useful feedback to the room. Far mic, center mic.

Aaron Hughes: Aaron Hughes. Just because Cathy called me out I suppose I’ll get up and say, yes, this change in text does support the intent that I certainly had originally requested being here, and the proposed text I fully support.

Paul Andersen: So you’re supportive now. Thank you. Further comments, questions? Look over to my left just in case remote is ‑‑ any remotes potentially? Jason Schiller.

Jason Schiller: Jason Schiller, Google. I guess I’ll talk about our second concern. And that was ‑‑ and that was regarding the new text. So there’s some concern about how to treat when a network has hierarchical serving sites. There’s a condition where you might have multiple level of serving sites and you might be out at a given level, and then levels further up in the hierarchy are also out so you can’t draw down additional space. But if you look at all your total end sites and all your total utilization, you might be less than 90 percent utilized. So my question is if you are 100 percent utilized at a higher level in your hierarchy, but your total utilization is less than 90 percent, would one qualify for additional space?

For example, if you had a serving site which was, say, your continent and you divided your continent into regions, so you had a second‑level serving site which was regions and you divided those regions into, say, metros, and then you divided those metros into particular hubs and you had edge routers and hanging from that you had end sites and you wanted to invent a new metro or a new hub, but you had no space from which to draw down in order to do that.

Paul Andersen: Wouldn’t the second bullet point address that, I think I heard? John?

John Curran: So the measurement is serving sites, and so even if there’s room in your hierarchy, if your serving sites are out at the measurement of the count of serving sites, then you’re out.

Jason Schiller: But the confusion you have here, for example, a multi‑level serving site and a regional‑level serving site. So if your regional serving sites are out, for example, you need to refill a region, so at the regional level you’re 100 percent utilized, but if you just look at end sites and look at the first‑level serving site above that, you might be only 60 percent utilized.

John Curran: Give me a moment, but keep taking –

Paul Andersen: So it’s so many levels too early in the morning, Jason. Let’s go to the front microphone while John contemplates the question.

Owen DeLong: Owen DeLong, Hurricane Electric, ARIN Advisory Council. I believe for that purpose what you would do is come back and say that the serving site definition you wish to apply in your current template or website submission, as the case may be nowadays, would be at the level that you are out. And then that level is clearly at more than 90 percent utilization in that particular serving site where you are out and you move forward.

Paul Andersen: Owen, while you’re at the microphone, are you in support or against.

Owen DeLong: I’m fully in support.

Paul Andersen: Thank you. Far microphone stage left.

Rob Seastrom: Rob Seastrom, ARIN Advisory Council and Time Warner Cable. And I’m in support of this proposal. I think that Jason’s concerns are well founded given the years of IPv4 austerity that we labored under, and that there’s sort of a knee‑jerk reaction among all of us to look for interpretation of policy proposals to be able to exert tight control over resources.

But our way of thinking about this sort of thing is evolving. And I suspect that that will be a concern that will be substantially less or nil a few years hence. I talk to members of ARIN staff who have made PEZ dispenser metaphors that IPv6 allocations should work like a PEZ dispenser; that you walk up and you flip it and out comes one. The level of scrutiny that one expects for v4 addresses is just not going to apply here. So I think that if you can fill out the form asking for more addresses properly and, as Owen said, show, hey, at this level of aggregation in our network, we’re out, we need more, that you will indeed be rewarded with a new allocation. So that’s my analysis of the level of concern that’s appropriate here.

Paul Andersen: Just to reiterate, you’re in support of the policy?

Rob Seastrom: Absolutely.

Paul Andersen: Before we go to the mic, John, go ahead.

John Curran: The definition of serving site is such that if customers in any way assign to it, there’s a list, but non‑inclusive list, of examples, including things like data centers and POPs. If it’s used to terminate customers or connect customers, then it’s a serving site. And that definition is sufficiently flexible that it looks like it could apply to any pod of a hierarchy in an ISP. So an ISP who says this layer is out of address space, I can’t continue my current plan, as long as they fill out the application noting that, they would be getting more address space under this. So the answer, Jason, is yes, there’s enormous flexibility in hierarchical assignments if this is implemented.

Paul Andersen: Comment from that, Jason?

Jason Schiller: Jason Schiller, Google. Thank you. Both concerns have been addressed. I support this policy.

Paul Andersen: You support. Thank you.

(Applause.)

Paul Andersen: Let the record note the applause. Front and center.

Milton Mueller: Milton Mueller, Syracuse University. Just a meta-comment about the ‑‑ it seems to be a family resemblance between this proposal and the 3GPP one that’s coming up in the sense that in both cases you’re talking about what is the ‑‑ where is the aggregation point at which you count utilization. And there are some concerns about how this can be gamed, I guess, which are legitimate.

But as I think Robert suggested, when you’re talking about v6, the issues, you can afford to be much more liberal than if you’re talking about v4. So I would also support this policy for v6 but would be looking for some kind of more well‑understood way of handling this problem of what is the proper site of aggregation. If this becomes an issue in the future, we may need to have a better grasp of what’s going on there, how it could be gamed, what’s a proper way to handle it from a conservation standpoint, if indeed conservation is even necessary.

Paul Andersen: Okay. Thank you for the support, and I think the extra comment is something the AC can work with on other policies. Rear microphone, and I think we’re almost out of time. If you want to approach a mic now would be a good time.

Dave Barger: Dave Barger with AT&T. Following on the last couple of comments, what Rob said a minute ago, applying IPv4 way of thinking to an IPv6 policy, I generally understand where this is going and most of the terminology, but I’m getting bogged down, though, again in the definitions of utilization versus allocation. So if you have an addressing plan with several levels of hierarchy, and, as we’re talking about, you may be at a given serving site, you’ve allocated address space and that’s 90 percent plus used, then by that definition you should be able to apply for a new allocation.

Or if you’ve ‑‑ the way I’m thinking about this ‑‑ if you’ve allocated 100 percent of your IPv6 address space from the top level down to all of your serving sites, does that also qualify you for another allocation? And if it does, then we need to change the first bullet under B where it says shows utilization of 75 percent, because don’t we really mean showing allocation of at least 75 percent?

Paul Andersen: I think Heather should address this.

Heather Schiller: A little bit how to read it. So if you look at B, qualifies for subsequent allocation, if they meet any of the following, and those are bullets. The first two already exist in policy. The one that’s bolded is the third option we’re adding. So those are ‑‑ if you think about it, they’re “or"s. Either 75 percent in the total address space or 90 percent in any serving site, or 90 percent allocated to serving sites.

So if you think of the last item, sort of like I’ve taken my net block and I’ve subnetted it out and I’ve applied a block for New York, a block for L.A., a block for Atlanta, and now I’m all out of buckets and I have a new city I’m turning up, and I need more address space rather than trying to do something hinky with the address space I already have, it’s just adding a third method of justifying an additional allocation from ARIN that’s not based on number of actual assignments made to end users.

Dave Barger: Quick follow‑up question. So the new item, then, that’s in bold there, so wouldn’t that essentially replace the first bullet?

Heather Schiller: No. They’re three different ‑‑ they’re sort of three different ways in which a network can grow. And whichever one you kind of hit first, depending on your sort of network deployment, you may hit the third option before you hit any of the other two.

Dave Barger: I’m in support of this.

John Curran: The short answer is imagine a network with multiple cities with multiple POPs per city and serving customers. B, the first bullet under B, is if the customer growth is such that the assignments to customers throughout the total address space results in 75 percent utilization.

The second bullet is ‑‑ that’s interesting. The second bullet is if 75 percent or more ‑‑ the second bullet is if one of those cities or one of those POPs hits 90 percent, then that’s a situation where they need to grow and they need to expand that one, but they’ve allocated fully all their space. The last one is a new city opening up where they have no allocation to make. All three of these are possibly distinct events that an ISP might have to respond to.

Paul Andersen: Just as a reminder before we go to our next one, we have remote participation. If you’re out there, feel free to ask a question. I have Kevin Blumberg next.

Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. So this has gone through a number of meetings, and the one thing to mention is that during those meetings people have brought up that this is a real‑world problem and they’re being impacted by it. Really, this problem ‑‑ this policy is here to support our early adopters, the ones who made the mistakes at the infancy of their network designs. And it’s also to hopefully address the issue of people making mistakes and not being significantly penalized in these early days of v6 so that they continue without having problems because they forgot that they were going to deploy something, or whatever the case may be. People are going to make mistakes. We have the luxury, thankfully, with IPv6 to allow those mistakes, to not cause significant harm to a company. So that’s just what I wanted to add in. And I am in support of this.

Paul Andersen: Center mic.

David Farmer: David Farmer, University of Minnesota, ARIN AC. Would it be helpful if we explicitly put the “or"s in just so that ‑‑ because there seems to be some confusion whether those were “or"s or “and"s, and I think this would be the kind of thing we could do going into last call because it’s really just ‑‑

Paul Andersen: It does read any of the ‑‑ turn my head the right way ‑‑ meet any of the following criteria. I think that’s fairly clear.

John Curran: Staff has indicated the language is sufficiently clear as is.

David Farmer: Thank you.

Paul Andersen: David, didn’t hear if you’re in support or not.

David Farmer: Yes, most definitely.

Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. As an early adopter of v6, we’re fully in support of this policy. What I wanted to get to, though, was I thought one of the gentlemen asked about utilization versus allocation. And if you read the definition of utilization that was in the original v6 policy that this is based on, that definition provides that anything assigned to a serving site is basically considered fully utilized at the point that it’s allocated to the serving site. So utilization and allocation are sort of interchangeable at upper levels of the hierarchy because it doesn’t make sense to measure utilization any other way in this context.

Paul Andersen: Thank you. Last call. Last call for a comment. Please approach the microphones if you’d like to make a comment and line up. Closing the mics. And remote participation? The final word.

Louie Lee: Louie Lee, Equinix, chair of ASO Address Council. I’ve heard from my own operations team that we have this concern that we won’t be able to allocate based on older ‑‑ we won’t be able to get more space based on older criteria. But this helps us. Thank you.

Paul Andersen: So you’re supportive?

Louie Lee: I’m in support, yes.

Paul Andersen: At this time we’d like to thank Heather for her presentation.

(Applause.)

John Curran: Thank you, Heather.

Paul Andersen: You are freed. Since this is our first policy, I just thought I would remind what we’re going to do now is we’re going to provide input as a community to the Advisory Council by doing a show of support, a question asking how much show of support there is for this policy as written in your book. So if you can hear the sound of my voice, either in this room that I’m in or online, you may participate in this process. Those in the room I’ll ask a question and then I’ll ask those who are in favor and those who are against, and I’ll ask you to raise your hand. Our team of expert counters will mobilize shortly to do that.

And those on the remote participation, I believe staff are providing you the method by providing input. So, for everyone, I know it’s early. Do one quick stretch break. If you can hear my voice, you’re more than welcome to participate in this process. Are our counters ready?

John Curran: Ready.

Paul Andersen: The question I would ask: Those in support of policy 2012‑2: Subsequent Allocations Utilization Requirement as written in your text, I would ask those who are in support of that to raise your hand now.

Paul Andersen: And keep it up until I ask you not to. Nice and high. No hanging chads, please. Just another moment. Those on remote participation, if you would, please. You can lower your hands, I’m told. Now those opposed to the policy as written, please raise your hand nice and high. I assume our counters were good on that one. Just a moment as we tabulate the results. We have to add up also the remote participation. On the matter of 2012‑2, those in favor, 41. Those against, 0. Those in the room and online, 98. This information will be passed to the Advisory Council for their consideration. Thank you.

John Curran: Thank you, Paul.

(Applause.)

John Curran: Okay. We are right on schedule. And at this point we get a little refreshment break. Folks are encouraged to head outside. We’re going to head out to the area where we have our refreshment right outside. We will resume here at 11:00 a.m., picking up with the global reports. Thank you.

AFRINIC Report

Adiel Akplogan: So I’ll quickly take you through the AFRINIC Activity Update. So to give you a very brief overview of the organization today, we have 37 people working full time, and basically working on core activities, the registration service and also a few on our engineering projects.

This quarter we have allocated almost 500,000 IPv4 addresses, which represents twice what we’ve done through the same period last year. And what has impacted that is the increasing number of new types of business coming into the region requesting IP addresses. And it’s something that we’re dealing with daily, almost daily now, because many virtual regions from RIPE region are setting up and moving that service into the region and requesting address from us.

Right now our policy doesn’t prevent anyone to do that. As soon as the service has been operated from the region, they can obtain an IP addresses from us. So we still have even with that 3.7 /8 IP addresses in our pool. So that is attracting people and implementing the strategy plan around that, trying to guess when we run out so to give them a little bit of time, all kind of information or justification along those lines.

At the same time we are continuing to push and help operators in our region to move into IPv6, at least running it in parallel with IPv4. We have also noticed significant growth in IPv6 allocation lately. We have about 30 percent of our membership base that also have IPv6, but unfortunately only 14 percent of them really announce those prefixes.

So we are reversing our training activity to try to address that and address other challenges that we’re seeing in the region as well. And we’ll talk a little bit more about those in the next slide. In terms of IT and engineering, we have some projects which are familiar to you, like RPKI, DNSSEC infrastructure, which are things we are working on actively right now. We’ve have also launched on the DNS anycast infrastructure. We developed that originally for our own infrastructure, but we start offering the service as well to DNS operators, ccTLD operators in the region where we host the secondary DNS on our own anycast.

So this project is taking a very interesting development lately because we are receiving more and more requests from our members in that. And even in our member survey that we did recently, that comes up as one of the key services that our community is expecting us to continue to work on. So we have more than about even 15 ccTLD who joined that project ‑‑ program right now, and there are a few more lining up to host their DNS on our infrastructure.

We also continue the Whois cleanup project with the community. There has been a policy in that regard in the region lately. The policy didn’t get through yet, but proactively we are doing that with the community.

We are also working on a routing registry. As you know, we are one of the areas that doesn’t provide a formal routing registry service to our members, and we are developing our own routing registry as well so that routing information can be stored in the region and on AFRINIC database. One new thing that we are working on, we’ll probably release by our next meeting, is the extension of our member portal to the new membership process.

We have noticed that this has come up from more than two years’ observation and data collection that where our members having more issue right now is during the first membership setup process. It goes from the address planning to answering some basic questions.

So what we are trying to do is to provide them a very intuitive and interactive interface for the new member process at the upfront, which will give them as much as information up front before even the hostmaster gets involved in the process, from basic mathematical analysis of their need to what they are going to pay to what is the information we will request from them up front, so that when it reach the hostmaster, the hostmaster can really address their need very quickly.

This also is because we ‑‑ with what I’ve said before, with big virtual operators coming into the region, with what we are seeing from mobile operators in the region, we are a little bit worried about small ISPs in the region who have difficulty getting the resources. So if we do not provide them sufficient help and support in the process, we will be running out of IPv4 when majority of small ISPs will be ‑‑ continue struggling to get resources.

So it’s a way of helping those small ISPs who don’t have dedicated resources and get people to manage their number resources to be able to get IP addresses from us as well. We have six policies on the discussion right now in the region. The first one is to review IPv4 address allocation process and procedures. There is another policy on IPv4 allocation to academic networks, which has raised a lot of discussion on our policy discussion list, in fact.

We have an inter‑RIR IPv4 address transfer policy, Whois database, database cleanup, anycast assignment to network in our region. And a last policy, which is related to reverse DNS. That policy in fact requests assignment before we delegate reverse zone on any assignment, not allocation, but the assignment mainly, which objective is to mainly ensure that all reverse delegation are properly documented in terms of assignment.

We have also adopted a new bylaw which is quite changing a little bit the way we operate as an organization. The new bylaw, for instance, has reduced the size of our Board from 13 to 9. We got rid of the director completely and we have added on top of our regional sub-regional representation in the Board, two non‑regional directors. This is to allow the Board to be more efficient and as well to catch up for the lack of I’ll say candidate nomination at the regional level because sometime we end up to ‑‑ because we want the regional diversity, we end up with people, a nominee, who doesn’t have all the necessary skills as we have requested.

Another major change in our bylaw is the membership. We have now three category of membership. The registered member, mainly representing Board. And they are registered because they are those who are formally registered according to Mauritius’ association law for association. We have some limitation there. We have resource member representing LIR and end user, those who receive resources from AFRINIC.

And we have a new category, which is associate member. This category of membership is open to anyone in the region that want to become AFRINIC member, targeting regulators and other organizations that have interest in attending our meeting, but because they’re not member, they have some issue formally participating or even attending our region ‑‑ our meeting.

We have also now a separate nomination committee from our election committee. Before it’s the same group of people that handled the nomination and also the election. Now we have a very dedicated nomination committee that deals with finding and selecting good candidates for the Board. And we have the election committee mainly made of AFRINIC staff and people who are appointed by the Board.

We have also an Advisory Council now in the bylaws which we call the Council of Elders. And this Advisory Council is appointed by the Board and made of the chair, former chair of the Board, who are not serving on the Board anymore, are automatically appointed the Council of Elders that provide advice to the Board.

As an RIR, and specifically serving the region, developing region, we have a few challenges. Some of them are common to all the RIRs, some of them are very particular to our region. And if you remember what happened at the WCIT, some of the analysis clearly showed that it is the north against the south.

So we have some specific issue there in our region on two aspects, the government and also the business. For the government, for us, it is how do we efficiently engage them in what we do, help them to fulfill their role as government in an efficient way, because as government they feel like they have a role to play in supporting the Internet development in their country and in their region. But right now they are kind of lost in that process. So one of the challenges we have is to help them, support them throughout that process so that they can understand what their role is and how they can effectively interact with their community that in fact is working on the technical aspect of this.

Another challenge that we have, which is also very important, is that the business side, how do we get business and decision‑maker in fact to understand the importance of IP address in their development and growth strategy. We talk about IPv6 several times, and we usually say that there are no operators, we say that there is no demand on IPv6. But generally for those who understand the important role, the strategic role of IP numbers in their business, it’s obvious for them that they have to go to IPv6.

What we have noticed is that, specifically in our region, is that generally corporation and organization, when you start moving up in the hierarchy, you find out people don’t really understand the importance of the IP address in their business. They understand customers, but they don’t really understand what IP address means for them.

And we think that if we manage to solve that issue, we manage to get the right information, the right message to those decision‑makers, we can solve other problems that we are having, which is IPv4 ‑‑ IPv6 adoption, but also in our region, particularly, usage of IPv4 globally. So it is a challenge we are trying to address, and we are doing that through different initiatives from capacity building, training, to small events, one‑on‑one discussion with corporate, and also reviewing our whole training program to align them not only to network operators but also to corporate networks, how can we help people who run corporate network to understand the importance of IP addresses generally.

There are many of them out there who don’t even know that is something important for them. Then this is the last slide inviting you to our next event, the Africa Internet Summit, which will host AFRINIC 18 as well. The whole event is from the 17th to the 21st June. It will happen in Lusaka. You are all invited. It is a new format of our joint meeting with AfNOG. We hope to have an AFRINIC and AfNOG event jointly.

This time we have ‑‑ we’ve branded the whole event Internet Summit with the objective to in fact open it a little bit and widen the scope, not addressing only pure technical issues, but bringing in other important issues for the Internet development in the region, along with AFRINIC policy development meeting as well. So you are welcome to the next AFRINIC 18 meeting and the AFRINIC Internet Summit, so thank you.

(Applause.)

John Curran: Louie, front and center.

Louie Lee: Louie Lee, chair of ASO Address Council, Equinix. Adiel, thank you for the presentation. The new RIR, the routing registry, is that going to be incorporated with the Whois more like RIPE, or is it more like ARIN where it’s two separate implementations?

Adiel Akplogan: It will likely be incorporated with the Whois and the RIPE NCC.

John Curran: Far mic, Bill.

Bill Darte: Bill Darte, ARIN AC. Thank you also, Adiel. You’ve come a long way, and it’s wonderful to see that. In your second slide I believe you said there was 30 percent penetration of IPv6 through the membership, dual allocations, and then subsequently it said 14.4 percent. And I just wanted to make sure I understood that. Is that roughly 50 percent of that 30 percent that have the dual, or is that 14 percent of the membership has visibility?

Adiel Akplogan: It is 50 percent of the 30 percent are visible. That means we have 30 percent of our membership who have both IPv4 and IPv6, but among those only 14 percent…

Bill Darte: Got it. I just wanted to make that distinction. I think that would be something for us to present as well. I think it would be nice to know of the allocations that we have in the ARIN region as a whole whether we ‑‑ what percentage of those are visible. I like that statistic. Thank you.

John Curran: Okay. Any other questions for Adiel? Thank you, Adiel.

(Applause.)

John Curran: Okay. Next up we have the APNIC Report. Philip Smith.

APNIC Report

Philip Smith: Thank you, John. Good morning, everybody. I’ll quickly go through the APNIC update here. Basically the folks back in the office gave me a rather large chunk of slides to try and present, but I’m not going to try and race through those in the ten minutes I’ve got. So we’ll just give you some of the highlights from the Asia‑Pacific region.

So going straight in. So the v4 address transfer services. So as you probably know, support for intra‑ and inter‑RIR transfers. This is a preapproval service. It’s an opt‑in anonymous listing. The four brokers listed so far. We have of course the Mailing List. The logs of the transfers are kept in public. Fees are applied, and that’s about 20 percent of the transfer block’s annual fee. This is payable by the recipient within the APNIC region of the sources transferred out of the APNIC region and then is paid by the source, if it’s transferred.

The inter‑RIR transfers, so far there are have been six from ARIN to APNIC. So that’s from November 2012 to probably about last week, when this slide was done. Transfer time is taking one to two weeks, so it’s pretty quick, successfully transferring a live network. So that basically means that the resources are transferred while the address space is actually being used by the operators in question. The ARIN and APNIC stats of course will overlap one day after the transfer, because, well, we live in a different time zone, significantly a different time zone from North America.

Looking at just the general transfers. This goes back like the last two years or so. The blue shows the general market transfers. The orange you start seeing there appearing from November of inter‑RIR transfers. So the blue, of course, is just the regular transfers that happened between our members. The transfer market size, not really a great deal if you look at the graphs. There’s a big spike in October 2011. And that was just before the introduction of the ‑‑ or reintroduction of the means testing for the transfers. So a lot of folks rushing to beat that particular deadline. Otherwise it’s been I would say fairly quiet.

As Leslie mentioned, we’re in our final /8. You can see just looking on the bottom left there, the trend of delegations from our last /8. Yes, there are quite a few. If you extrapolate that tiny little line to, well, running out of the /8, it will keep us going until 2030. But you can prove anything with a straight line, I guess. But that’s really what it’s looking at. It’s not a massive run on the bank on the final /8.

The v6 delegations, these are cumulative numbers, so the v6 delegations are going onwards and upwards. The delegation count for 2012 is slightly down on previous years. I don’t know what that’s indicative of, but that’s pretty much where we’re at. The ASN delegations, again, you probably saw from Leslie’s graph that we are handing out 4‑byte AS numbers. It’s not uniform across the region. I see a huge chunk going to New Zealand of all places. I’m not entirely sure why. They’ve obviously solved some problems that the rest of the Asia‑Pacific region have not solved with the utilization of 4‑byte AS numbers.

Looking at membership growth. This is interesting. We’ve got definite membership sizes and we’re seeing significant growth in the very small and small members. What we expect is happening is that a lot of service providers who previously would give address space to the end customers, end users, are now telling those end users, all right, just go to APNIC, get address space from them directly.

So we’re seeing quite a growth in that very small, where people are coming, getting the final /8, the /22 out of that, and even sometimes going for the v6 32 at the same time. And we’re seeing significant growth, and that growth is continuing this year as well. Looking at distribution by economy. No real surprises here. 39 percent in China, 24 percent in Japan, Korea, Australia, and then so the rest go. That’s as of the 1st of April this year.

As for the policies, Einar covered a little bit of this, but we’ve implemented two policy proposals, Clarifying Demonstrated Needs Requirement in v4 Transfer Policy, that was implemented February, and the prop‑101, Removing Multi‑Homing Requirement for v6 Portable Assignments. Two others did not reach consensus. We just had APNIC 35 conference in Singapore in February, and the two proposals there didn’t reach consensus. One has been returned to author for continued development; the other one has been abandoned.

As for training, the training team is sitting inside my portfolio, and the trainers, all three of them, have been pretty active for the last three months. Considering that Australia is about the size of the continental US, we’ve got quite a big region to get over, so it will be all the way from Wellington in New Zealand to Ulaanbaatar in Mongolia out to Hyderabad and Bangalore in India. So 30 courses in 12 locations, 600 participants. We do e‑learning. That happens every week. Free courses given every week with 326 participants for those 39 courses.

As for v6 in the community, Miwa Fujii, as some of you know, leads the v6 program for APNIC. We had the v6 plenary at APNIC 35 in Singapore, which focused on the mobile network deployment. ICANN meeting just last week in Beijing. There’s a v6 workshop there as well. And of course APNIC provides the Secretariat services for the Asia‑Pacific IPv6 task force. And that task force met at APNIC 34 in Phnom Penh in September last year as well as APNIC 35 in Singapore this year.

As for the APNIC Labs, Geoff Huston, George Michaelson are busy away measuring v6 amongst a lot of other things that they do. They have the v6 capability tracker looking at client v6 capabilities using Google Analytics tool, also measuring the end‑to‑end capability of v6 clients per economy, looking at v6 preferences by AS number, so we can work it out how ready each AS number is for using v6, as well as the v4 address report measuring the v4 free pool exhaustion.

So you can get more information, the lab’s website as well as the BLABS, which is Geoff and George’s blog about the work they’re doing. And pictures showing some of the summary from the website they’re doing, looking at the v6 readiness. You can see more of this by going to the lab’s website.

Upcoming conferences. We’ve got APNIC 36 in Xi’an, China. Before you think where on Earth that is, it’s the home of the Terracotta Warriors, which some of you have probably heard about. If the APNIC conference doesn’t excite you, please at least come to Xi’an and you can fit this into the site. That’s the last two weeks of August. First week is workshops. We started those last year. Second week is the conference which includes, of course, the policy meeting.

And then APRICOT 2014, Bangkok, Thailand, February of next year, which includes the APNIC 37 conference as well. So those are the two upcoming events which we have which you’re all invited to join us in. Finally, Internet Governance Forum. Of course, the eighth annual IGF is in our part of the world. This year it’s in Bali, Indonesia, towards the end of the year. If you’re interested in participating or coming along to that, please do so. We will be, of course, helping quite a bit being in our region to ensure successful IGF.

And Paul Wilson, the APNIC DG, is participating this year in the Multistakeholder Advisory Group. And of course Internet organizations such as APNIC have supported the IGF pretty much since it started. And that’s all I have to present. Any questions?

John Curran: Any questions at all? Thank you.

(Applause.)

John Curran: Next up we will have the LACNIC Update and Juan Peirano.

LACNIC Report

Juan Peirano: My name is Juan. I work as hostmaster and policy officer in LACNIC, and these are our LACNIC news. We wanted to talk about membership update, resource update, IPv4 and v6 allocations and assignments, something about RPKI, the FRIDA Program, and the previous and upcoming meetings and policy proposals we are being discussed.

First the membership update. We are hitting the 3,000 members. That’s a huge deal of members for us. Most of them are ‑‑ I don’t know if you can see that, the chart. Most of them are small and small/micro. So it’s designations between /22 and /19. And I think it’s probably ‑‑ the reason is the same reason it’s happening at APNIC. And more and more ISPs are telling their customers to ask IPv4 to us and not to them.

This is the status of our pool, IPv4 pool. We have 2.6 /8 left. So we are running out, as all of us. We’re all on the same page. So this is what we have until April the seventh from this year. Regarding v4 and v6 allocations, we have something like 130 allocations and assignments in IPv4 and v6 every month. We have some peaks near our meetings. That’s because the meeting is coming and the people get anxious to get their own IP.

And in October and in November those are our busiest months. Speaking about IPv4 allocation assignment in /8, we have allocated and accumulated from April 2012 to March 2013 approximately 1.4 /8s in IPv4. In IPv6 allocation assignments, we have almost 300 members ‑‑ 3,000 members, sorry. More than half of them have IPv6. That’s great news. We reach more of them, more of them have IPv6. That’s the members that have IPv4 and IPv6 and the members that only have IPv6. This year so far we made 138 allocations, and the past year we made something like 578.

About the RPKI. We have almost 300 signed prefixes, and the v4 space covered by ROAs is something like almost 6 percent of the announced space. Something about the FRIDA Program, a program that we have in LACNIC and in the region to help organizations make their projects go on. We have two calls. One of them it’s the FRIDA Awards. That’s for existing project. And we have the FRIDA Grants. That’s also for further research.

And good news is since February 2012 FRIDA is part of the Seed Alliance. That’s joint initiative with APNIC and AFRINIC, and we’re very excited about it. About our previous meetings, we have our tenth anniversary meeting in Montevideo last October. That was the picture that Cathy showed. Thank you, Cathy, you’re making us look good. So thank you. We go back to back with LACNOG 2012. We discuss 11 proposals, and four of them reached consensus. The four proposals that reached consensus are these. This slide is not correct. The Board ratification was in March, not in February. Sorry about that.

The proposals are post‑exhaustion IPv4 IANA‑distributed allocations/assignments, update on RIRs‑on‑48, allocations of IPv6 address blocks larger than a /32, and eliminating the requirements for initial IPv4 end‑user requests. All four were ratified and they are already now in our policy manual. About upcoming meetings. We have our next meeting in Colombia in May. We’ll be back to back with LACTLD. We’ll have great speakers and talk much about IPv6 and DNSSEC and RPKI. And in our policy forum we’re going to discuss four proposals: Eliminate the use of the term “dial‑up,” our own inter‑RIR IPv4 address transfer ‑‑ that’s work for you, Einar ‑‑ requirement to sign up for RPKI when requesting additional resources, and modifying requirements for ASO AC nominees.

This is our last news. We have a brand‑new product in LACNIC. It’s called Certi
6, and this is basically a methodology developed by LACNIC to be used by software testing and IPv6 rules for testing and Internet technology experts to certify that a software application is running properly over IPv6. So this is really exciting. And I think that’s it. I don’t know if you have any questions.

John Curran: Any questions on the LACNIC update? Thank you very much, Juan.

(Applause.)

John Curran: The next update will be the RIPE update from Axel Pawlik.

RIPE NCC Report

Axel Pawlik: If you say so. Good morning. My name is Axel Pawlik. I’m the managing director of the RIPE NCC in Amsterdam. Quick update. Some numbers from basically last year. We are up with our membership. Actually by now we have surpassed the 9,000, rather large number. We’ve seen surprising growth over the course of last year, and still see that. The result financially for last year is about two million Euro surplus. We budgeted, as we tend to do, for a red zero, but, well, with all that growth that didn’t happen.

And of course also our fee schedule has changed to be very simple. One member, one fee. It’s 1,800 euros per year, and we’re actually looking forward to bring that down a little bit as well later on this year in May, actually.

Now we have this favorable tax status with the authorities in the Netherlands that basically acknowledge that we are not for profit in all that and that we can keep up to I think three times of our turnover in a clearinghouse, basically accumulated surplus that we’re not taxed on, which is great. But they’ve also indicated in the past that should anything happen to our association in terms of fees or significant offering of services to non‑members, then we should please go back to them and renegotiate. So we thought after this significant fee change, maybe it’s not a bad idea.

They have initially welcomed us for talking to them. They think we can ‑‑ we’ll be able to keep this tax status. More or less they look at three times turnover. Whoa, that’s quite a lot for a small grouping like yourselves. Please argue with us a little bit. So we are preparing to do that. But it’s looking friendly.

Hey, yeah, no more IPv4 addresses. You know that already. We’re issuing quite a number of /22s from the last /8. It’s as expected quite and no surprises there for us. However, it’s not as if we weren’t talking to people for many years already that this was about to happen. Some of them are waking up now in the purchase of IPv4 addresses. Like they need them urgently for the growth of the businesses and could we please give them some. No, we can’t.

The amazing thing here is that they accuse us of not having a transfer policy. So we can’t even get the unused legacy space out of America and use them ourselves. So that’s our failure now. On the other hand, when we say no, we have a policy that precisely is under discussion, and maybe it will be dumped because there is not enough support, but where are you on the mailing list? Oh, no. No, no, we can’t be bothered. We have to do work. All right. Fine. We find it very interesting. And of course it always brings up the old argument of, oh, these old mailing lists, aren’t they stuffy and who does this stuff anymore? Shouldn’t we all move on the policy process into Facebook and stuff like that?

(Laughter.)

Axel Pawlik: Hey, it’s easier to say that, right?

John Curran: Dislike.

(Laughter.)

Axel Pawlik: Yeah. Us too. So we have to look at that. And then communications in general obviously. Because we don’t seem to be reaching our members in ways that keep them all happy and ourselves happy. Okay. Couple of policy proposals here that have been implemented now. Transparency in address book transfers. I think Milton brought that up. That’s been implemented.

Run out fairly was about, as the name says, to keep things very orderly just prior to IPv4 run out. That happened. It worked. So we can basically revert that again. Time limits for temporary Internet assignments. It was too short and we have recommended that. Current ones that are being discussed, or maybe are not being discussed enough, is the policy for inter‑RIR transfers of v4 address space. It’s not very popular. Hmm. Like I said, people who need it don’t see it and don’t take part enough in the discussion, so it’s an uncertain future here.

Inter‑RIR policy transfer policy proposal. Going ahead. Yeah, it’s being discussed. PI assignments on the last /8. That is apparently popular. On the other hand, wasn’t that meant to be for major operators coming in later, preserving their future? Hmm? Services to legacy Internet resource holders. Here that’s an ongoing thing as well, a bit of a saga here. Again, that’s the latest version of the proposal being discussed.

And that’s the no need one. Basically saying, hey, we ran out of IPv4. Let’s forget about this. We all moved on to IPv6, didn’t we, already and deployed it nicely, so who cares about that before thing? On the other hand, yeah, some want some space there. Conservation doesn’t really make sense because it’s gone more or less.

As to need demonstrations, if you are prepared to part with some money maybe to get that space, isn’t that implicitly some need that you’re demonstrating? Well, we don’t know of course. Also an important factor is the correctness of the registry, obviously. And we ourselves are thinking that we should keep the thresholds for any changes of the database of the registry as low as possible, just to encourage people to update their entries there. So as easy as possible, and v4, yeah, it’s about to be dead anyway, right? Being discussed, of course, people have noticed that there is a certain link to other regions on this one and proposed transfer policies. It’s all very interesting.

Certification/RPKI. Yes, we are doing it. We are continuing development and deployment. It’s not really pretty, but it’s up and to the right. It’s being used, or played with at least. We do training. Webinar is there. We have a couple of policy issues. We are with this activity nicely in between two fighting camps, as you probably know, you’ve heard about that. Some of our members in the community love it and others hate it. So what are we supposed to do? And we recently discussed this with our Board as well, and the Board guidance there is to throw it to the policy process and see, for instance, for our PI space certification whether there is support for that significant, and then we’ll do that.

Right. RIPE Labs. Some highlights. Oh, we have been pummeled by Paul Rendek for a long time, but we don’t have statistics per country, and we need that. And Paul of course does our external relations, and he hears that quite a lot. So finally we’ve gotten around to doing something like that. RIPE Atlas update is there as well. I’ll talk a little bit about that. RIPE NCC Roadmap, basically we’re trying to tell our members and greater community where we are with certain activities and software development and try to make that a bit more transparent.

And, of course, as you know, RIPE Labs is not only for the RIPE community as in terms of orders but we’re also taking other interesting stuff, this CAIDA Research, for instance, correlation between country governance regime, how democratic or transparent a country is, and the reputations of their IP address allocations. Interesting reading.

Other stuff, IP Analyzer, we’ve re-implemented that and it helps our members to administer their resources very nicely. RIPE stats are basically all sorts of information about a given number block. Have a look. Database software has finally been rewritten. It’s shrunk a bit. It’s easier to deploy and look at and to change and maintain.

RIPE Atlas, we have about now I think 2,800, 2,900 probes out there, and we are also looking at deploying what we call anchors. Basically somewhat bigger machines that ‑‑ slightly bigger machines that can be used as a target for measurements and might also host other services.

Membership survey. Yes, we do them regularly, about every two years. We have held focus groups within our service region. We’ve got some feedback from that, and the idea of the focus groups basically is to give us questions to ask in the actual survey. We launch a survey at the end of the upcoming RIPE meeting, and then of course we’ll eagerly look at the results from that and take our cues from that.

The next RIPE meeting, as you probably already know, is going to be in Dublin in May. You all are very welcome and we expect you to be in force, obviously. And after that, if you can’t make this one, there’s the next one coming up in October, and that will be in Athens in Greece. And of course you will be welcome there as well, but first go to Dublin. And that’s me. Thank you.

John Curran: Any questions for Axel? The next report is the IANA Report. I’ll have Selina Harrington come up and give it.

IANA Report

Selina Harrington: All right. I’m Selina Harrington. I work at ICANN. I’m going to try to keep this activities update brief. There are more slides than I was expecting would be in the presentation, and I don’t want to run over into your lunch break. I’ll start talking about the IANA functions contract. It officially began in October of 2012, although it was awarded to us in June. And the total length of the contract could be up to seven years. It’s three years with two possible two‑year extensions.

This is probably a little bit difficult to see, but in performing the contract, one of the requirements is to hold a number of public consultations on certain aspects of functions that we perform. And so we’ve already held some. I’m going to go over a few of them. The customer service complaint resolution process. We actually have an escalation process that was developed several years ago in 2006 and we were kind of asking whether the process we already have is okay, if there are changes we should make, should it be replaced.

And we did receive five comments. The key inputs included making sure that the process is available to customers, making sure that people are aware of the process. It doesn’t get used very often and either we’re doing a very good job or it might be because people don’t know the process exists. And we also at the Beijing meeting ‑‑ it’s not on this slide, but there was some feedback about maybe changing the name from customer service complaint resolution process to customer feedback process. Just sounds a little bit better.

We also held a consultation on measurements of our performance as far as allocating IP addresses and AS numbers. And the comments we received included clarifying definitions, introducing a KPI for policy implementation schedules, which I’ll talk about that a little bit later, and publishing performance data in both machine‑readable and human‑readable formats.

We also had a consultation on our secure notification process, which is how we reach out and notify the community about any events or planned maintenance or new services. And we received two comments. One was a commercial proposal, and the other was just a statement of satisfaction with ICANN’s proposal.

This consultation, the root zone KSK rollover consultation, is actually open. And if anybody has any experience or any comments they would like to make about this one, we would greatly appreciate it. And you can find that list of consultations on our website at iana.org/reviews, and you will be able to find this and where you can comment. We’ll also have more upcoming consultations related to policies and procedures, user instructions, and dashboards.

So now back to policy implementation. And the IPv4 global policy based on the input from the public consultation that we held, we did create a separate recovered IPv4 pool registry, separate from the regular IPv4 registry. And we’re currently developing software that will be used to select the addresses once the policy’s triggered.

And the registry actually looks a little bit different than our other IP address registries. You’ll notice it has a range instead of the CIDR notation, and that’s just because of the length of the registry would have been extremely long if we had done it the other way.

And now back to DNSSEC. Our most recent key signing ceremony was held in our Los Angeles facility in February. And along with ICANN staff and auditors, trusted community representatives from across the world, all the different regions, attend these ceremonies. They attend them on their own dime and they’re there to make sure ‑‑ to watch what we’re doing and make sure that the ceremony is open and transparent. And we’re greatly appreciative of their participation.

Another project that we’ve been involved in for the last four or five years is a business excellence project, and basically it’s helping us to identify ways that we can improve our processes and the way that we perform the IO functions. And this graph ‑‑ or arrow is ‑‑ indicates the self‑evaluations that we have performed. Each January we have a self‑evaluation, and it’s steadily been increasing. And this year we’re actually preparing for our first external evaluation. So hopefully by the time the next ARIN meeting comes around, we’ll have some good news about that.

And last but definitely not least we have two new staff members. On the left is Dalini Khemlani. She is an audit associate working on SysTrust audits and also key signing ceremonies. And on the right is Paula Wang, and she is a request analyst working on root zone change requests. I think that’s it, so thank you very much. If there are any questions, I can do my best to answer them.

John Curran: Any questions on the IANA report?

Selina Harrington: If you think of them later, I can send the answer out through the PPML.

John Curran: Thank you.

ARIN-2013-1: Section 8.4 Transfer Enhancement

John Curran: If everyone will take their seats, we’ll get started. Okay. Everyone welcome back. I’d like to start out with some brief announcements. Coming up, the next thing we’ll do is our policy consideration of ARIN‑2013‑1: Section 8.4 Transfer Enhancement, we’ll have the Policy Implementation and Experience Report, and then we’ll have the open microphone discussion for the Policy Experience Report, any other discussions regarding policy, and then we will ‑‑ doesn’t say it, but we will then ‑‑ after that we’ll have some closing announcements and then tonight’s social. So it’s a policy full afternoon.

Okay. So moving right along, ARIN‑2013‑1, and we have the introduction, which I’ll do. Recommended Draft Policy 2013‑1: Section 8.4 Inter‑RIR Transfer of ASNs. This is the ARIN Policy Proposal 183 submitted in October 2012. The shepherds, Scott Leibrand and Robert Seastrom. Presented at Public Policy Consultation at NANOG 57. The AC found the current version met the principles of Internet resource policy and recommended it for adoption. That means it is eligible to be advanced to last call after this meeting. The text and assessment are online, in your Discussion Guide.

So summary: Would allow the transfer of ASNs along with IPv4 address space in an 8.4 inter‑RIR transfer and applies to all the same criteria currently listed for IPv4 to ASNs. Status at other RIRs. No similar proposals or discussions.

Staff comments or concerns. The policy is clear as written, it’s implementable policy to handle. Legal assessment. No significant legal issues. Posts for the Draft Policy. No posts for or against. So at this point I’m going to ask Scott Leibrand to come up and give the AC introduction to it.

Scott Leibrand: Good afternoon. This one is going to be fairly short presentation because it’s a fairly minor change. So I’ll jump right into it. But I’m going to try and talk slowly for the people in the back who have to take notes. So remind me if I start talking too fast. The problem statement here is pretty simple. ASNs can be transferred under 8.3 within the ARIN region, but right now they’re not allowed to be transferred between regions under 8.4. This would harmonize the two policies and make 8.3 and 8.4 similar in allowing ASN transfers.

It does that by adding the underlined red text. It’s pretty simple. Make ‑‑ add ASNs and fix the grammar and make sure that we’re not tying v4 and ASNs in that last bullet. So why would we want to do this? It would allow idle resources to be recovered. If there’s people who aren’t using ASNs and other people who need them, if there’s people who particularly need 2‑byte ASNs when we no longer have them, whatever the situation is, same justification as for v4 addresses but much less urgent. It would allow those resources to get put where they’re needed.

Perhaps more important than that, it would allow us to update the registry to reflect what people are actually doing. As we heard earlier today, there’s definitely some concerns that the registry can get out of date if there’s too many burdens against allowing people to update it to reflect reality. So one incentive we have is to make sure that those transfers get registered properly in the ARIN database, and in the database of another region if we’re transferring them out of region.

As I mentioned before, we already allow ASN transfers. This just allows them across the board, and it does that by making the policies in 8.3 and 8.4 the same. The main drawback that I’ve noticed that I’ve heard people express is simply that this might not be necessary. There’s a few reasons that people think that. One would be that they didn’t think that ASN transfers were necessary in the first place, and so they don’t think these are necessary either. That’s a little bit of an argument that’s already been hashed out, so I won’t go into too many details. But there’s still folks who think this isn’t necessary for that reason.

Also this won’t take effect and won’t have any effect unless there’s another region that allows transfer between RIRs of ASNs. Right now there’s no policy proposals on the table for other RIRs to allow inter‑ASN transfers. Until and unless that happens, this will simply be a matter of cleaning up our policy to be the same and won’t actually change anything as far as what actually happens.

Also there’s a number of people who think this isn’t important because, unlike IPv4, ASN resources are not in short supply. There’s 4‑byte ASNs. As we heard earlier, they’re fairly widely used in some regions, other regions not as much. But even in the regions that aren’t moving to 4‑byte ASNs yet, we’re not quite out of 2‑bytes like we are with IPv4 addresses.

So there was an Advisory Council assessment that we made of this proposal. It’s up here. It’s I believe in your Discussion Guide, but basically we identified moderate support for the proposal. Some opposition mostly around those things that I highlighted with regard to it being unnecessary, but as the shepherds, we believe that it was worthwhile to allow this. It wasn’t going to really do any harm. And the Advisory Council voted to recommend it to the community for discussion, and if the community agrees, that would allow us to send it to last call. So we’ll open it up for discussion and I’ll step back.

Paul Andersen: Thank you, sir. Is it just me or is it darker in here? So I actually only see a silhouette. So front mic, please.

Owen DeLong: Owen DeLong, Hurricane Electric, ARIN Advisory Council. Speaking only for myself, this proposal is a pretty bad idea. It takes an existing bad idea that we adopted for whatever reason and makes it even worse. Further, there’s an additional drawback that’s not on the list, which is that having the ability to transfer 2‑byte ASNs in may further exacerbate the laggardly rate at which 4‑byte ASNs are getting adopted in our region.

Paul Andersen: I’ll take it that you’re opposed to the policy.

Owen DeLong: Very opposed.

Paul Andersen: There was somebody there but they’ve disappeared. If you’d like to discuss this policy, could you please approach in favor or against. Please approach a microphone now or start typing in our remote participation. Somebody at that mic. I’m not kidding you; it’s a silhouette right now.

Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC, speaking on behalf of The Wire. From earlier this morning we discussed 2‑byte ASs are drawing down ‑‑ correct me if I’m wrong, John ‑‑ in the region. So one of the arguments about having an ASN transfer policy earlier on was that they’re in limitless supply. Well, they’re in limitless supply of 4‑byte, not in 2‑byte, and that runout is now occurring.

I don’t see a reason to not have this in the ability for other regions if they had issues with 4‑byte, to allow for it. My preference would have actually been to limit this to 2‑bytes because that would have taken care of legacy 2‑byte as well as depleted pool. But as it stands right now I see no problem with this.

Paul Andersen: So you’re in favor, obviously?

Kevin Blumberg: I’m in favor.

Paul Andersen: It’s going to be a short discussion. That’s the problem with having this right after lunch. Everybody’s got a bit of food.

John Curran: People who feel strongly about this policy one way or another please approach the mics. The AC has to actually take your input to do their job. So input is helpful.

Paul Andersen: Please approach now. Don’t all rush at once. R.S., anything on the phone line, so to speak?

Rob Seastrom: Silence.

Jason Schiller: Jason Schiller, Google and ASO AC. I don’t feel strongly in support or opposed. I feel that transferring ASNs is a bad idea, but that ship has already sailed and do not want to revisit that discussion. However, I think there’s some issues with this policy proposal as written. Looking at 8.4, going down the bullet points, the first bullet point we added ASNs to. So that’s properly taken care of. I’ll wait a second while everyone flips through their guides.

So the first bullet point we added ASNs to, so that’s properly dealt with; the second bullet point generically refers to source entities outside of the ARIN region must comply with whatever rules are in place. That’s generic enough; the third one, however, says source entities within the ARIN region will not be eligible to receive any further IPv4 address allocations or assignments from ARIN for a period of 12 months after a transfer approval or until the exhaustion of ARIN’s IPv4 space, whichever occurs first.

Unlike the next bullet, where we inserted some text about the transfer must be of the same type, we did not do that in this bullet. So my reading is if a source entity within the ARIN region transfers an ASN out of region, this will prevent them from getting IP addresses from ARIN for the next 12 months. I don’t think that’s what was intended.

Paul Andersen: One moment. We’re getting the presentation back up.

Scott Leibrand: I’ll start my answer, and if we can get the text back up, I’ll go back into that. The third bullet is not modified in any way by this proposal, which means that this particular restriction which currently applies to IPv4 addresses would not apply to ASN transfers.

So it’s not that the restriction would become more onerous, as was originally the problem with bullet 4. The way this is currently structured, we are only modifying the first bullet and the fourth bullet. So the third bullet, which speaks about IPv4 address allocations or assignments and speaks about exhaustion of IPv4 space, would be unchanged, would continue to apply to IPv4 resources but would not apply to ASNs.

So what that would mean is that even if you received a transfer of ASNs from ARIN or from another party through ARIN, you would still be eligible, if you had a further need, to go back and get ASNs from ARIN. I think that is appropriate because we’re not in a shortage situation, particularly 4‑bytes. If I get a 2‑byte ASN from a transfer and I have another need for another project for a 4‑byte ASN, I don’t particularly see a reason we would need to have a restriction of this type for ASNs. If you disagree, I’d like to hear it.

Jason Schiller: The way I read this after a transfer approval, whether that be an IP address or an ASN, the source entity within the ARIN region would not be eligible to receive any further IPv4 address allocations or assignments.

Paul Andersen: Of the same resource type.

Jason Schiller: No, the third bullet does not say of the same resource type.

Paul Andersen: So you’re talking about in the current NRPM, the current ‑‑

Jason Schiller: Yes. The third bullet in the current NRPM, which is not being modified, has an unintended consequence that now ‑‑ that you can transfer ‑‑ if the policy was to go through and you’re able to transfer ASNs and such a transfer would be approved, under this third bullet I believe it would prevent you from getting IP addresses for the next 12 months.

Paul Andersen: Is that your understanding, Scott?

Scott Leibrand: This might be a question for John, because that’s not how ‑‑ so the intent of the ‑‑ the intent was obviously not to do that. I can see how you could read this to mean what you just said. So at that point I think it becomes a question to staff of interpretation. Staff noticed the change that we made in bullet 4 having an effect that they would have considered to be very similar, and they’ve suggested alternate text that would avoid that. They didn’t notice anything with the third bullet. So I’m not sure if that means they interpret it differently than you do or if it’s something they missed.

Paul Andersen: I was going to say we have another ‑‑ we had someone at the mic, I was going to say we could go there while you have a moment to process. Let’s go to the back microphone and give John a chance to read it.

David Kessens: I’m David Kessens, Nokia Siemens Networks. It took me a lot of time to actually stand up and say something about this policy. My problem with this is like you’re putting pages and pages and pages, and the oversight of the situation is like, I mean, what is the big deal with transferring AS numbers? You know, we should just allow it and be done with it, and also having it ‑‑ added to another very complicated policy and get over with it. I just don’t see what this is helpful for.

Paul Andersen: You’re supportive of this?

David Kessens: That’s why I feel mixed. I’m supportive of this, but, on the other hand, I’d much rather have a separate policy that says simply for an administrative fee you can transfer AS numbers to wherever from wherever, whatever. I think this is a lot of overly complex stuff that you really don’t need for this topic. There’s really no problem here, so…

Paul Andersen: That’s not the policy I’m thinking of. But that’s useful feedback to the AC. John, you had a question to the clarifying question.

John Curran: Regarding Jason’s comment about the third bullet of NRPM 8.4, the third bullet reads: Source entities within the ARIN region will not be eligible to receive any further IPv4 address allocations or assignments from ARIN for a period of 12 months after a transfer approval or until the exhaustion of ARIN’s IPv4 space, whichever occurs first. By context, we read that as after an IPv4 transfer approval, but the bullet does not say a IPv4 transfer approval; it says a transfer approval.

From the intent of the policy and the prior corrections of the text, I’d recommend the AC editorially correct this. It doesn’t change the meaning, but it would make it real clear if the third bullet read “after an IPv4 transfer approval.” Do you see that? I think without the word “IPv4” in there, Jason’s correct; that an ASN transfer could preclude you from IPv4 resources after.

Paul Andersen: Jason, did you want to follow up on that?

Jason Schiller: Jason Schiller, Google. Yes. An alternate way to fix this would be to specify an IPv4 address or ASN transfer approval and make the restriction be in kind, like you’ve done with the other bullet.

Paul Andersen: Jason, if the intent was clarified, you’d be in support or…

Jason Schiller: Like I said earlier, I don’t feel strongly about supporting or opposing. I think the transfer of ASNs in general is a bad idea, but that ship has already sailed.

Rob Seastrom: Remote participant Kevin Otte made an observation and a question for the room that touches on our discussion this morning. He says: Seems like vendors not supporting 4‑byte ASNs and IPv6 are what’s holding us back. How do we encourage the vendors to get it in gear rather than having to do policy workarounds?

Paul Andersen: Anyone want to respond? All right. Thank you for the comment. Bill Woodcock.

Bill Woodcock: First, I think I agree with many of the other people in here that this is layering a bad idea on top of a bad idea. And I can’t really see supporting it. But beyond that, going back to the prior bad idea, we’re very quickly running out of unique identifiers that people can use in their internal systems to identify other networks.

And the more transfers we have of different kinds of things, the harder it is for people to keep their internal systems that identify their external peers working. And AS numbers were kind of a last‑ditch on that. And if we ‑‑ there are going to be a lot of people systems who will break if we go much further down this road.

Paul Andersen: Scott.

Scott Leibrand: I’ve got a follow‑up question on that. Are you worried that someone by transferring an ASN is going to still have peering sessions up with that ASN and that there’s going to be operational impact from that? I would imagine that this would be mostly used for unused ‑‑

Bill Woodcock: That is a security concern of many people. It’s not the highest concern for me, because it’s a security concern that only affects people who don’t pay enough attention to security. But that’s a lot of people, admittedly. My concern, no, is with all the administrative systems that people build to track peering and track who is what organization and where they should have peering sessions and to automatically build those peering sessions and so on and so forth. There are many, many, many millions of sessions out there being built by code.

Scott Leibrand: Right.

Bill Woodcock: And organizations change names. They get bought. They get sold. Blah, blah, blah. You’ve got to have some way of tracking through all that in your systems. And a lot of people use ASNs for that because it’s ASNs that actually define how the peering session gets built.

Scott Leibrand: I understand all that. Yes, my day job is peering, but what I don’t understand is why someone would go through a transfer of an ASN that is currently being used in this manner ‑‑

Bill Woodcock: Doesn’t matter if it’s currently being used, right? It matters if it was ever used. We’re talking about ones that have ever been used.

Scott Leibrand: I think I understand your concern. I’m not sure I share it, but that’s another discussion.

Paul Andersen: So we’re getting to that point. So I ask if you wish to make a comment, either start typing if you’re remote or approach a mic in the next 60 seconds or so. And then otherwise we’ll close the mics off. Center microphone.

David Farmer: David Farmer, University of Minnesota, ARIN AC. To Bill’s comment about not ever being used, ARIN already ‑‑ I believe ARIN already recycles ASNs that have been returned to it, so this is already a problem. Okay. Thank you. And since I’m up at the mic, I do support the policy.

Paul Andersen: Thank you, David. Seeing no one approaching the microphones, going once, twice ‑‑ center microphone.

Jason Schiller: Jason Schiller, Google. There’s been some discussions about some possible changes in text. I would just ask that when you call for the show of hands you ask a very clear question.

Paul Andersen: So noted. John Curran.

John Curran: So as noted from the context of the third bullet, we would interpret source entities within the ARIN region will not be eligible to receive any further IPv4 address allocations for a period of 12 months after an IPv4 transfer approval, and I believe they’ll make that as an administrative correction. So that’s the version of text we’re working on, unless someone proposes something else. Just for clarity.

Paul Andersen: Not to put you on the spot, Scott, but do you see that as an administrative clarification you’ll be recommending?

Scott Leibrand: Yes, I do see it as an administrative clarification. I’d have to go back and look and see what the new PDP says as far as the sequence of events about how we make it, but it’s so minor that I wouldn’t worry about it. We’re talking about this policy as intended and as John clarified, and I think the more important question that we need to ‑‑ the AC needs input on is whether you think that this is a good idea to make this change, and we can figure out the precise details and the precise policy, but the underlying question is: Should we allow inter‑ASN or inter‑RIR ASN transfers? Yes, we have too much jargon in this community as others have noted. I can’t even keep it all straight.

Paul Andersen: So with the microphones closed, and I’ll ask my counters to ‑‑

John Curran: Let’s thank Scott.

Paul Andersen: I apologize. I did not see you. Milton, the last word.

Milton Mueller: I don’t know if it’s the last word or not. I’m just a little bit surprised. I’ve heard two commenters, somewhat predictably, talking about layering a bad idea on top of a bad idea.

Paul Andersen: I did hear that, yes.

Milton Mueller: I want to get this clear: Are you saying we shouldn’t be doing IPv4 address transfers at all?

Bill Woodcock: No, that AS number transfers are kind of pointless. Right? If an AS is picked up as part of a merger or acquisition, then probably the peering sessions should go with it, right? If one company goes out of business, it gets ‑‑ its AS number gets reclaimed, somebody else picks it up, there’s no good reason for the successor company which had no connection whatsoever with the prior company, there was no transaction, there was no acquisition, there’s no continuation of other resources, for that to be identified as the prior company in a lot of people’s systems.

Paul Andersen: Noting that Mr. Woodcock jumped in very quickly, I was going to say that while that’s an interesting question, this policy does deal with ASN transfers currently, and there will be an open mic later where that can be dealt with. At this time we’re only dealing with a policy that will allow inter‑RIR ASN transfers. Center mic.

Owen DeLong: Owen DeLong, Hurricane Electric. I will clarify, as Bill did, that when I said a bad idea on top of a bad idea, I meant inter‑RIR transfers of ASNs are a bad idea layered on top of intra‑RIR transfers of ASNs.

Paul Andersen: Thank you. Thank you, Scott, for your presentation.

(Applause.)

John Curran: We’ll get the tabulators ready.

Paul Andersen: Before we start tabulating, this morning we had a record, I think, 41 shows, so let’s see if we can beat it. If you can hear the sound of my voice, I ask that you take a moment to reflect. The first thing I note to Jason’s point is, if I’ve heard John right, is that the text as written would be as expected but that there probably will be a clarification just for a degree of certainty.

So I will ask the question on the matter of 2013‑1: 8.4 Inter‑RIR Transfer of ASNs, I’d ask those who support the policy as written to raise their hands high. Just a few of you are halfway over. So nice and high, please. And if you’re a remote participant, please signal now. You can place your hands down.

Those who are opposed to the policy as written, please raise their hand. You may place your hands down. We’ll wait for the results. On the matter of 2013‑1, we have 102 participants remote and in the room. In favor, seven; against, eight.

So given that result, I will ask a second question, which is just more general. Taking out the specific text but looking more at the problem statement or the rationale, I’d ask for a show of support on those that would encourage the AC to continue work on this matter.

All those in favor of the AC continuing work in this matter, please raise your hands now or remotely participate. Nice and high. I know it’s post‑lunch. Thank you. And those opposed to the AC continuing work on this matter, please raise your hand. Please lower your hands. Milton, this is normally the time that the new AC member starts singing and dancing to kill the time.

John Curran: That’s right, we forgot the hazing ritual.

Paul Andersen: On the question on whether the AC should continue work on this, in favor, eight; against, 12. These two pieces of decisive and clear input will be passed on to the AC for their consideration.

(Laughter.)

John Curran: Okay. Thank you very much. We’re right on schedule, and the next item is the Policy Implementation and Experience Report with Leslie Nobile.

Policy Implementation and Experience Report

Leslie Nobile: Okay. Good afternoon, everyone. Okay. Policy Implementation and Experience Report. We’ll start with the recently implemented policies. This is the easy portion. I’m reporting on which policies Registration Services has implemented since ‑‑ thank you ‑‑ has implemented since the last ARIN meeting. So there have been four of them implemented.

The first one is the removal of renumbering requirement for small multi‑homers. This is an interesting policy in that staff presented this in a policy experience report, and you as the community took that up and made it into an actual policy. And it’s working quite well.

Reassignments. The second one is reassignments for third‑party Internet access, TPIA, over cable. And we were having many problems. Our customers, our cable customers in Canada were having very difficult problems getting additional allocations under the existing policy.

And this was presented to you as the community again and this new policy was implemented and it’s being used quite often. It’s very effective and people are quite happy with it. The third one was revising Section 4.4, Critical Infrastructure Reserve Pool Size. That’s the title of it, but that’s not really what the policy is about. It’s kind of interesting. We reserve a /16 for critical infrastructure. That’s the existing policy in 4.4.

What this policy does is it says that the new gTLDs, the new ones being approved by ICANN, they cannot qualify under this particular policy out of that /16 reserve. They can qualify under any other ARIN policy for space, but they cannot use that /16 reserve for their allocations or assignments. And there is a/23 maximum size for new gTLD.

And the fourth one is just aligning 8.2 and 8.3 transfer policy criteria. So the Policy Experience Report. This is the opportunity for the staff to tell you all how things are working with policies, existing policies, and make recommendations on changes.

So we review our existing policy set, and we’re basically looking for things that aren’t working as intended, things that don’t work for our customers. Ambiguous text, inconsistencies, gaps, maybe missing policy where there needs to be one, or overall effectiveness. And we’ll identify areas where new or modified policy might be needed, and we base that on our operational experience, what we see every day and whether a policy is working, as I said.

And based on also customer feedback. Customers tell us this just doesn’t work. If we hear it more than once or twice, you have to figure there’s some kind of a problem. So these are the kinds of things we’re going to bring to you. And then we’ll provide feedback to you, to the community, and make recommendations when appropriate.

So we’ve reviewed four policies or potential policies in this report. So it’s kind of a long one. The first two we brought to the community before two years ago, and the community opted not to make any additional policy around these. These two continue to be very problematic for us. So we’re bringing them back to you in the hopes you’ll reconsider. The first one is what is an end user and what is an ISP. And those definitions are in 2.6 and 2.4 of the NRPM.

The second one is can an RIR issue space to an organization outside its region. And that’s become very, very prevalent and very problematic, quite honestly. And that definition is in NRPM 2.2 and it’s what is an RIR. The third one is merger and acquisition transfers. We think there’s some missing text in that one. And then the fourth is ‑‑ there is no policy, but leasing IPv4 address space. We’ll bring the topic up and discuss it a little bit.

So the first one. NRPM 2.4 says what is a Local Internet Registry. We don’t even use that in the ARIN region. We use ISPs. But this is all we have to go on. So it basically is an Internet registry that primarily assigns address space to the network services that it provides. LIRs are generally Internet service providers. And then end user says an end user is an organization receiving assignments of IP addresses exclusively for use in its operational networks. Very vague. So the issues. There’s no current definition of ISP in NRPM anywhere. So we just have to determine what an ISP is. Most people know when they’re an ISP, but not always.

The real problem that we’re seeing is that some of these newer technologies don’t clearly fit into either category, so requesters don’t know what they are and we don’t know what they are sometimes. And examples of these are cloud computing services or infrastructure as a service, providers or VPN providers. It’s just not clear where they fall. And, as I said, it’s difficult for both staff and customers to determine whether they’re an end user or an ISP in some of these situations.

And with the recent policy change to the three‑month supply, it may be advantageous and a bit more attractive for people to be end users because they can get the 12‑month supply under the end‑user policy. Questions. Should there be a clear definition of end user and ISP in NRPM? Should we have a very distinctive definition? Should staff determine whether an ORG is an ISP or an end user or should the organization be able to choose? In recent years staff has directed people one way or another, but, as I said, there’s some confusion on both parts, and we really do need some guidance.

Should an ISP be able to switch to become an end user and vice versa, thus allowing a different set of policy criteria? It is actually easier to qualify under the end‑user policy and you get a 12‑month supply. So it’s just a question to consider. Potential solutions that we’re just going to throw out there. Decide that it’s not an issue, which happened previously. Harmonize the ISP and end‑user policies so that there’s no distinction between the two. Have one common set of policy criteria for all requesters; no ISP, no end user. Or add clear definitions of end user and ISP from a technical perspective and add some real meat to it and delineate their technical characteristics.

So that is the ‑‑ those are just a couple of things we came up with. I’m going to move on to the next. I guess we’ll do questions after. NRPM 2.2. What is a Regional Internet Registry. The primary role of RIRs is to manage and distribute public Internet address space within their respective regions. That to us means that ARIN issues resources for our customers within our region, generally for use within our region. That’s how we’ve interpreted that.

But that’s all we have to go on. There’s not much policy text around that. So the current practice is you have to have a legal presence in the ARIN region. And we are now asking requesters to provide geographical location information on where the resources will be used. That is something new that we’ve added to the request process so that we know up front exactly where it’s being used and you know up front that we want to know.

And then we ‑‑ this has always been ‑‑ the third one is something we’ve been using for years. We say you have to route the least specific prefix within the ARIN region. So there’s some issues. And I’m just identifying a couple of the bigger ones right now. This requirement to route the least specific prefix within the ARIN region, it can be gamed. It worked for years when there was no depletion and everybody could go to their respective RIRs and there were no issues. It worked and people were fairly honest about it.

It seemed to be effective, but we’re seeing some very changing behavior in the ARIN region and we’re seeing it happen rapidly. Things in the past several months have gone ‑‑ have become very interesting. So we have a couple of different scenarios. We’re seeing the cases where the foreign entities are creating shell companies in the ARIN region. So they have the legal presence.

They’re buying transit here. They get IP addresses directly from us. And then they’re forwarding packets for use by equipment and customers out of the region. So they have some equipment here. They have a presence in a datacenter. They have a rack or something and they have the shell company and the routing least specific prefix. So they kind of meet our requirements, but all of their customers are out of this country.

And in fact my staff told me that every other request that we’re getting literally is coming with foreign names that they cannot read, cannot pronounce. They just don’t even recognize them. So there’s a lot of requests coming in from foreign companies, foreign entities at this point. We’re also seeing ‑‑ this is an interesting one. We’re seeing some US hosting companies that are now adding the majority of their customers out of region. They feel like the business is booming in other regions, so they’re adding customers there.

And they have equipment in the ARIN region, in a datacenter typically, but almost all of their customers are out of the region. And typically their customers are foreign hosting providers from a region that has exhausted its last /8, and in this scenario a lot of those small Web hosters that they’re issuing space to are then issuing space to their customers and they’re in turn coming back to ARIN for additional space using that for justification. They’re using their ARIN space to get additional ‑‑ to get space directly from ARIN as opposed to from an upstream.

We are seeing a rapid increase in the amount of IPv4 address space being issued to these ORGs. I don’t have data on that, but I believe that there’s been some studies done recently. Apparently there was a presentation last week that did look at this, and you may want to look at that for additional information. But I can tell you that we’re issuing a lot of space. And I can tell you that these guys are coming back about every three weeks, and every time they come back they get a larger prefix allocated to them. So this is really quickly. This is no three months; this is three weeks that they’re coming back.

And for us it’s really difficult to verify whether the space is being used efficiently. When you’re in region we can check websites, we can understand them, we can read English or we can make a phone call or we can use Google Maps, but when you’re out of the region we can’t do any of those things because we don’t understand the language.

So it’s become very difficult to actually verify the legitimacy of the data. And obviously there’s an incentive to hoard address space because IPv4 is being depleted and is out in some regions. So people cannot get additional space in RIPE or in APNIC.

So questions. With v4 depletion imminent in some regions, should RIR shopping be allowed? Should organizations from other regions be coming to ARIN to get their address space for use out of the region? Should there be clearly defined criteria requiring that the resources be used within the ARIN region? Should we continue with our current practice or should we make decisions based on where the customers and the equipment serving those customers are located?

Some potential solutions. Well, we don’t have a lot, but we can decide it’s not an issue and just continue with our current practice, which, as I said, is problematic. Or we can add more stringent justification requirements for out‑of‑region customers and use. For example, we were thinking something like this, a policy that says at least 50 percent of the equipment and the customers must be physically located in the ARIN region, potentially we could add the routing the least specific prefix, which we do now, if need be. But some ideas.

Okay. Moving on. Am I going too fast? I’m asking the girls in the back. Good.

The third one is NRPM 8.2, mergers and acquisitions. This is a really simple one. We’re just missing a couple of words that were in the previous policy. It says now “ARIN will consider requests for the transfer of Number Resources in the case of mergers and acquisitions under the following conditions,” so it limits to just mergers and acquisitions.

So what we see is ‑‑ quite often we see corporate reorganizations as the reason for a transfer. Organizations are deciding that they wanted to build businesses in different ways and they want to shift resources to where their business might be booming, et cetera, there’s just all kinds of reasons, but this is what we see quite often.

And there’s no longer a reference to that in the 8.2 policy text, whereas there used to be. The 8.2 policy text used to say ‑‑ the previous version of the transfer policy said “ARIN will consider requests for the transfer of Number Resources only upon receipt of evidence that the new entity has acquired the assets which had, as of the date of the acquisition or proposed reorganization, justified the current entity’s use of the Number Resource.”

So we’ve just kind of continued allowing corporate reorganizations under 8.2, but we would love for the policy to actually follow the practice. So what we do right now is we do allow them. And there are very strict conditions on that. A parent organization can transfer resources to a child organization or vice versa as long as the child is a 100 percent owned subsidiary.

It gets very complicated to try to find all this information. So we will, of course, ask for legal documentation in compliance with the policy, and we will verify utilization also. We just have a potential solution, which is to just add corporate reorganizations back into the text so that it says “ARIN will consider requests for the transfer of Number Resources in the case of mergers, acquisitions and corporate reorganizations under the following conditions.” Just inserting two simple words.

Okay. Leasing IPv4 address space. There’s no policy for this, but we’re hearing lots of reports and rumors that organizations are leasing IPv4 address space to other ORGs. Obviously with depletion, people do get creative. This may not be an ARIN matter. We’re not sure but we’re bringing it to you because it could have operational impact if people are leasing space to each other and not updating the registry, then we’re going to have inaccurate registry data.

So potential solutions: This may not be an issue for ARIN to deal with. You can decide not to even address it. Or perhaps create a new policy that requires that the actual party using the addresses be listed as an operational contact in Whois.

So allow the leasing but say whoever the ultimate end user is must be listed as a POC. Or create a new policy that would prevent the leasing of address space without needs‑based justification, because we really don’t know what the conditions are as people leasing address space. We don’t know if there’s needs based or not.

That’s all I have. Are there questions? I see the table. Milton, yeah.

Milton Mueller: I thought that was a ‑‑ I’m Milton Mueller, Syracuse University, Advisory Council. So is this the normal part of the ARIN meeting, because it seems to me like you set the policy agenda for the next two years for us.

(Laughter.)

John Curran: Let me respond. We provide this to let people know how policies are functioning or not functioning and how ‑‑ but it’s entirely up to this community to actually draft and write policy proposals and can disregard all of these. We use it in two ways. One, to let you know where there are issues with the policy and implementation, and also, to be fair, we have to continue to operate under the current policy manual. So we’re sort of describing how we’re handling these current situations so no one’s surprised a year from now when they say what do you mean that’s how you’re doing it? Well, this is how we’ve had to handle the current manual.

Milton Mueller: Let me say, then, you did a great job flagging really interesting and important issues. I would like to point out that almost all of them actually have to do with the scarcity of v4, and that surprise, surprise, when we’re giving out valuable resources for free over here and they’re available for a charge over there, that there’s arbitrage going on and people are pretending to be in the ARIN region when they sort of really aren’t.

The same thing with the leasing. That’s a function of our restrictive needs‑based assessment. So I like your list of policy options there. I think that was pretty right on target. One thing I wanted to ask you, why do we really care if people are from the ARIN region or not? I know they don’t pay membership fees to us, but if they’re pretending to be in the ARIN region and they pay us membership fees, why do we care?

John Curran: Face out there when you ask that question.

(Laughter.)

Leslie Nobile: Chris?

Chris Grundemann: Chris Grundemann, ARIN AC. The problem with potentially out‑of‑region networks, can you give us an estimate of what the scale of that problem is? You said you’ve been seeing this start to happen, coming back every three weeks for how much space? Maybe not real numbers, but in comparison to how much space we have left? What is the scale of this problem, or potential problem?

John Curran: This will probably become the dominant factor in our allocations with ‑‑ if we did a revised drawn‑out estimate based on the last month or two, it would pull it into potentially the first or second quarter of next year, with absolute certainty. It could be the end of this year with certainty. So we’re dealing in the ranges of very large blocks.

You have to be a little careful here, because allocations ‑‑ I don’t want to say anything that someone can backtrack and say you gave up organizations’ personal information, but let’s just say this is going to be the majority ‑‑ at the current rate this is going to be the majority of the allocations we’re making.

Leslie Nobile: And as I said, just one thing, that every time they do come back, they get a larger prefix. And that’s ‑‑ and if they’re coming back every three to four weeks, imagine.

Chris Grundemann: In that case, point of interest for everyone, that means we may not even have a full policy cycle to address that issue, even if we wanted to, right? It’s possible that we may not have that time?

John Curran: Correct. But it’s a lot easier if people know ‑‑ think it’s a problem if you folks work on it, it’s a lot easier to decide it’s urgent and uplift it to the Board if you actually are in consensus and have text as opposed to the Board holistically deciding we have a problem, which is probably not going to happen.

Chris Grundemann: I have one more question, if I can, on the leasing. One of the things you said as you were going through the list of problems was that under leasing you have no way of knowing if they’re leasing, if the lessee has need for the space. Isn’t leasing very similar to an ISP or LIR relationship where ‑‑ I would assume that if I’m a holder of IP space and I’m leasing it to someone, that I still have to justify my need to ARIN and so therefore I can’t get more space unless the lessee is actually using it efficiently.

Leslie Nobile: That is correct, yeah.

John Curran: It’s predominantly with address blocks that are underutilized that we’re now seeing, if someone were not to ‑‑ instead of transferring, if you were to become an extremely lightweight service provider, you could make a very large allocation to your new customer. It’s very hard for us to discern that.

Chris Grundemann: Thanks.

Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. I just want to go back for one second to the small multi‑homers. Had a quick question in regards to that.
One of the concerns back when the policy came out and everything was that there would be a run on the bank from these people. I’m just curious, because it wasn’t mentioned there, have people taken advantage of this in a growing number, or has it been utilized?

Leslie Nobile: No. Actually, just a few have come back. And that was the situation before, so few were using it and it didn’t seem ‑‑ yeah. No, there’s very few still coming back for those additional assignments.

Kevin Blumberg: Wonderful. And I wanted to touch on what Milton said, because it really plays to the heart of a bigger issue, as far as I’m concerned, which is all of these issues come down to the validity of the data. If somebody is scamming the system or playing with the system where that data is questionable or invalid or unusable, it’s have a deleterious impact on operations.

If we can’t talk to an abuse contact, because it’s some fictitious company ‑‑ now, it might be a legal company, but to me a shell company with no real anybody is fictitious. And if that’s the case, then we’re operationally impacting our region. If the ‑‑ if it goes to the leasing ‑‑ if the records are not being updated with correct information, we are affecting operationally. All of these situations are operational impacting issues.

And I’d like to echo that I think that we need to discuss this as fast as possible, and unfortunately based on the numbers you’re talking about, I think that unfortunately policy ‑‑ the policy cycle will have to get ‑‑ what’s the word? ‑‑ shortened to deal with these issues.

Leslie Nobile: Cathy.

Cathy Aronson: Cathy Aronson, ARIN AC. Chris said a bunch of the stuff I was going to say, so I’ll skip that. But with respect to the end users versus ISP text, I have always thought that the main difference was that if you were an ISP, then you were assigning to your customers. If you were an end user, you couldn’t do that. Right? And then an ISP was less expensive and had different requirements because they couldn’t subdivide their address space and assign it to their customers. Right? Is that ‑‑ I’m just trying to get my hands around ‑‑ because if you put them both in the same policy, then are we just going to ignore that? And I guess I wanted to know what your thoughts were.

John Curran: At present, in terms of the services that ARIN offers to an end user versus an ISP for an allocation versus an assignment, the services we provide are highly similar except for the ability to sub‑delegate. But in terms of from ARIN’s perspective, it’s almost identical, except for your ability to do that one task. The fees are very different. The new fee schedule has $100‑per‑record maintenance for an end user and has end user ‑‑ has ISP fees based on total address holdings. So it’s the question themselves of organizations that want to switch what they think they are, it becomes problematic if we don’t have a clear policy.

Cathy Aronson: Right. So that would be at this point an organization that is a solely assigning address space to their own infrastructure.

John Curran: For some organizations that are involved in ‑‑ if you’re a hosting company, it’s a soft allocation because the customer’s in your datacenter. So it could be either way.

Cathy Aronson: Okay. Thanks.

Leslie Nobile: David.

David Farmer: David Farmer, University of Minnesota, ARIN AC. So in regards to that customer or end user versus ISP definition, this is another one of the places or issues where the fee structure and the policy kind of intersect. So I guess the question I would have is which one’s going to control from a fee point of view. And I get confused. If the community wants to make policy that has a fee suggestion at the bottom of it, feel free to. But at the end of the day, the fees are set by the Board or selected by the members.

John Curran: So if it turns out you want to make a suggestion about end users and ISPs and how to handle that and has fee implications, that can be considered in parallel, just put that down in writing.

David Farmer: The point I’m trying to make is I think by definition us changing the definitions of either one of those have fee implications. And so the question is are we going to have one definition for fees and one definition for policy?

John Curran: No.

David Farmer: Okay. So then if we ‑‑ so then by definition we’re changing the fee structure through the PDP.

John Curran: If the community comes up with a recommendation for definitions of end users or ISPs or how organizations move between them, part of a staff assessment will be to talk about the implications for fees, and obviously that means briefing the Board and all of that. But you have freedom to suggest there. You just can’t set it by the policy process, because the Board also has a fiduciary duty.

David Farmer: I get that part. But if we make a definition that runs afoul of the fee structure, which controls, the policy definition or the fee definition?

John Curran: I promise you that one won’t get adopted without the other, since both go to the Board. I’m not sure I understand ‑‑ do you want to meet afterwards and go through it?

David Farmer: Maybe. I think what I’m trying to say is they’re inexorably linked.

John Curran: Yes, that doesn’t stop you from working on it. Does that help?

Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. I’ll be very quick. What is the policy if you have Acme Joe’s Enterprise, Inc., from 20 years ago who now decides to be Acme Joe’s Enterprise ISP? Are they allowed to switch from one way to the other, and vice versa, as the company changes?

Leslie Nobile: If they can show they’ve actually changed their business model and they’ve switched, yeah, their services, yes, they can change.

Kevin Blumberg: If a company fits within a definition of today, they can switch between end user and ISP and vice versa at any time?

Leslie Nobile: It’s not at any time. Actually, we allow a one‑time switch ‑‑ should I just explain? We’ve had people come in as end users even without switching business. Right? They thought they were an end user; three months later they decided they’re an ISP and they need to SWIP.

They used to technically have to SWIP, and we did DNS differently early on, so we would allow them to switch over to the different category, but the stipulation was that they would have had to have met the ISP policy. If they didn’t actually meet the criteria and they wanted to make a switch, we weren’t going to allow them. If you’re going to switch categories, we want you to be able to qualify under the new criteria as an ISP or an end user.

Kevin Blumberg: I understand that, but if somebody decides they were offering DSL, as an example, so they’re an ISP, they decide to get rid of DSL, all they’re offering is Web hosting, they want to switch from the ISP category to the end‑user category, do you allow that?

Leslie Nobile: Yes, we would allow that.

Kevin Blumberg: And you’ve mentioned that there’s a one‑time change limit. Is that arbitrary?

John Curran: So far we haven’t forced a single change because we’ve asked you to declare what you are, and so you can’t be telling the truth the first time and then a month later say I’m now something else, because one of your statements would be incorrect.

Kevin Blumberg: Thank you.

Leslie Nobile: Thank you for your time.

John Curran: Remote.

Rob Seastrom: We have a remote participant. Marla Azinger says: I would like to see the ISP and end‑user policy become one thing. I don’t see why any entity should be getting more address space due to a label. Technically every business plan model needs to plan one to two years out. It should be considered more that this proposal or this difference should be considered more in depth, just remove the difference so there won’t be a concern about changing an entity and how they run their business model.

Leslie Nobile: Okay.

John Curran: Milton.

Milton Mueller: I want to ask you to send me your slides.

John Curran: They’re online. On the agenda. They’ll be there.

Heather Schiller: As are all the past Policy Experience Reports, and you can see what we’ve done with the past ones how the current policy has changed. So no one brought up the part about using address space out of region.

So if you want to look at that slide and have a discussion a bit about that, about an organization that is based in the ARIN region and predominantly uses their address space in the ARIN region, recently being asked more interestingly about how and where their address space is going to be used, and my understanding in the past has been that people felt as long as the organization is in the ARIN region and predominantly using their space there, that if they want to get an allocation in their sort of home RIR and use it globally, that they’re welcome to do so. But no one talked about that, and that was one of the items you have.

John Curran: You said it. It’s possible for you to go to your home RIR and get a block use it globally. We recognize that. We have a few people who do it. And we expect to have use in the region even though you have incidental use outside the region. Okay. But now you’ve got two circumstances. One is where the use inside the region is incidental and nominal compared to 97 percent of the use outside the region.

And then you’ve got one where the use is entirely within the region, but the customers aren’t. And when they come back, looking for more resources, they say our datacenter is here, it’s located in your region, here’s our customers, though, and their customers are all located in another region.
So the question is ‑‑ that can be perfectly fine. We’re reporting it to you to let you know what we’re seeing. It’s our experience, which is why it’s the Policy Experience Report, and so we just want people to not be surprised at this use of policy.

Jason Schiller: Jason Schiller, Google. So the discussion about where the customer exists was something that actually surprised me. If I’m a transit provider and I’m offering T1s or DSL or OC‑48s, or whatever, and they terminate on routers inside the US in the ARIN footprint, I don’t necessarily always know where the other location of that circuit is, and quite often it’s international.
I’m not sure why that has a bearing, because topologically speaking they’re terminated in the US, which is inside the ARIN footprint.

I would say likewise for a hosting provider or a cloud computing provider, if the datacenter’s physically in the US and they’re selling the service to host it in the US, why does it matter that the service owner is outside of footprint.

John Curran: It might not. And the only reason we know of it is in the purpose of determining the veracity of the address usage we ask a lot of backup information, and that will get you to ‑‑ that will cause you to chase the other end of your T1 and find out where it is because it was a customer that you did allocate an assignment to. So we find this out in the process of verifying the requests for the next allocation.

Jason Schiller: So it matters, though, if a T1 is physically terminated in the US and the far end is in, I don’t know, Brazil. The question is: Should it matter?

John Curran: That’s the question we’re asking the community, yes. And that’s why it’s on the Experience Report.

Andrew Dul: Andrew Dul. With regard to the three points, I think the first one about a legal entity within the region is absolutely critical. The second one asks the requester to provide the information. I think that’s definitely appropriate. And I certainly would like to see that. However, we’re not policemen and there are very few chairs that we can rearrange on this ship. And at this point let’s just go down with the ship.

And while it would be nice if people route things in this region, I don’t think it really matters. The most important is that there’s a legal presence in the United States or whatever entity or other country in the ARIN region and that we have a way to enforce our contracts with them based upon our agreements with them.

Leslie Nobile: Thank you for your time.

(Applause.)

John Curran: Any other questions? One more.

Dave Barger: Dave Barger, AT&T. And I guess John ‑‑ probably direct it at John. So, John, we were talking about these entities outside of the ARIN region establishing a legal presence, setting up shell companies, and I think you said that’s definitely accelerating the v4 address exhaust. I think you said early 2013, 2014 is what you’re looking at.

Do you have a guesstimate ‑‑ if that wasn’t going on and if we could fix this problem quickly, do you have any kind of a sense about what that’s going to do with the exhaust timeline?

John Curran: Yeah. So I didn’t mean to say problem. We’re successfully deploying IP addresses and they’re getting used. If they were not as successfully being deployed this way, then it probably would get us twice the time. Some of the graphs show the end of 2014, early 2015. But it’s cut in half by the current early success, I guess.

Dave Barger: Then my two cents is, and I think the comment was made earlier, that this is something that probably sticks out more in my mind as far as the to‑do list, the idea of just setting up a shell company within the US should that really just constitute ticking off bullet No. 1 that was on the list, or does that criteria need to be stiffer and stronger and so on. So I have to think about it. Thanks.

Jason Schiller: Jason Schiller, Google. So just to close out the conversation as to where we are at this moment, my understanding is generally if a request comes in for a company that’s exclusively outside of the ARIN region that’s using the IP addresses exclusively for customers that are outside the ARIN region footprint on networking equipment that’s exclusively outside the ARIN region footprint and advertising that space from equipment that’s exclusively outside the ARIN footprint, that would get rejected; otherwise, it’s accepted.

John Curran: Further slide in the slide deck on current practice. If you look, we currently say you have to have a legal presence and we require that. We ask them where the resources are going to be used they have to say to some extent they’re being used in the region. And we validate ‑‑ I guess this isn’t in policy, but we validate that when they say it’s going to be used in the region it’s actually going to show up routed in the region with the least specific router.

Jason Schiller: I think that’s what I said in the negative, which was if it’s not advertised from equipment in the ARIN service region, not used by customers in the ARIN service region and by a company that doesn’t exist in the ARIN service region, then that would get rejected.

John Curran: Any of those fail.

Jason Schiller: Oh. Any of those fail. Okay.

John Curran: Yes.

Jason Schiller: Right. Sure.

Leslie Nobile: Okay. Thank you.

(Applause.)

Update on Resource Transfers

John Curran: This is an update on resource transfers. So, yes, we are doing transfers at ARIN; some bankruptcy‑related, some larger underutilized blocks. I’ll talk about inter‑RIR transfers, some of which we discussed today, ASN transfers, and legacy resources. So these are the IPv4 address space transfers within region that have occurred under NRPM 8.3. These are available on the website. And I think they’re slightly misformatted. They got a little larger in this font. But we do have transfers happening in the ARIN region.

Total IPv4 blocks transferred, the equivalent of 30,540 /24s. So a bit of space moving under the 8.3 policy. Total ASNs transferred, seven. People asked for a breakdown of where these are coming from. So the ones that were covered under an RSA prior to the transfer, six of the ASNs and approximately 4,638 of /24s equivalent of space. Covered under LRSA prior to transfer, 2,156 /24s, none of the ASNs. Not covered prior to transfer ‑‑ i.e., legacy and not having entered into LRSA ‑‑ 23,746 /24s, one of the ASNs.

In terms of transfer requests, try to give a little more insight into this data since people have been asking for it. Since January 1st, 2011, through March 2013 we’ve had 84 requested. We’ve completed 56 of them. We’ve denied ‑‑ 56 percent ‑‑ 47 of the requests. We’ve denied 16 requests, or 19 percent of the requests. Pending, 12 ‑‑ there will always be some pending because we’re always working on something ‑‑ about 14 percent. And abandoned ‑‑ if we ask you for information and you don’t show up, then eventually we will close it out as abandoned ‑‑ about nine, or about 11 percent. So that’s NRPM 8.3 within region requests.

Reasons for denial. We’ve gone through these before. Transfer to a party that doesn’t meet the operational need requirement. Requests to transfer blocks that you’re not the registrant of. Requests to transfer block size is smaller than a minimum. My favorite remains a /32 transfer attempt. Request to transfer blocks larger than needed by the recipient. The recipient can’t qualify according to need, then you need to refactor the request.

Inter‑RIR transfers under NRPM 8.4. We have had quite a bit of success. Our policy lines up with the APNIC policy. So recipients in the APNIC region are capable of doing inter‑RIR transfers. So far they’ve all been transfers to the APNIC region. Though we’ve had this request ‑‑ or not request, we have discussions from people interested in going both ways. They’ve all been to the APNIC region.

So here are the blocks that have been transferred. Most of them small, about a /23 and /18 ‑‑ pair of /18s. And the effective dates of their transfer. This information’s also online under the statistics under transfer. Under NRPM 8.4, equivalent of 135 /24s. Covered under the RSA prior to transfer, the equivalent of 68 /24s. Covered under LRSA prior, two /24s; not covered prior to transfer, 65 /24s. In terms of inter‑RIR transfers request processing, we’ve had 12 requests. We’ve completed six. We have six pending.

So don’t have a body of ‑‑ large enough to see more. We don’t see denied or abandoned at this point. Inter‑RIR transfers to and from the RIPE region. I think we highlighted this earlier, but RIPE Policy 2012‑2, Policy for Inter‑RIR Transfers for IPv4 Address Space, if adopted, we believe it would be compatible with ARIN’s inter‑RIR transfer policy, thus opening up transfers to/from parties in the RIPE region if all other RIPE policies remain the same.

RIPE Policy Proposal 2013, the No Need Post‑Depletion Reality Adjustment and Cleanup Proposal, if adopted, even after 2012.2 if then 2013.3 is adopted, it would then prevent transfers to and from the RIPE region until such time as RIPE or ARIN transfer policy were aligned by a further change. It would move it to a misalignment circumstance, even if the prior policy was adopted. Completed AS transfers. NRPM 8.3. We’ve had a few ASs. This is all within region. And we’re talking about inter‑RIR transfers at this meeting, which is the right‑hand side of the slide.

ARIN registered transfer facilitators, some people want help in doing transfers, whether it’s looking for space or if they have space. We have a transfer facilitator program, and the facilitators are available on the website and they are all familiar with our policies and seem to be quite good at this. Legacy resources at ARIN. We have people come up, particularly transfers, and ask about legacy. This information is on the website, I’ve presented it in other forums.

On December 3, 2012, NTIA published a set of Internet protocol numbering principles including recognizing ARIN as the RIR for the region, including supporting policies developed by the community through ARIN. It was made because of some uncertainty as a result of remarks made by the NSF General Counsel. Their statements are online. Consistent with NTIA guidance we continue the management of resources in the region through the policies that you develop.

And we don’t distinguish application of those policies between legacy and non‑legacy resources. They’re all subject to the registry policies that you establish. You can also see the NSF General Counsel letter, you can also see ARIN’s response to the NSF general counsel letter, and then you can see the NSF General Counsel letter, which indicates that the remarks were not a US government position but were his observations. All those are available on the website as well under legacy RSA at the bottom.

That concludes my presentation. We’re coming up right up on break, but I’ll take any questions. We will go on break and then we’ll come back for open mic session. But any questions on the transfer presentation? Go ahead. No? Okay. Any remote questions? No remote.

Open Microphone

John Curran: Okay. So it is now 2:39, and we have our open microphone session. It runs for 20 minutes, and a break. And then we’ll come back with it. Open microphone is available to talk about actually any of the topics you just saw, which is why we give the Policy Experience Report first, and also any other policy matters people want to talk about.

Open mic is often used for people to find people who want to work on similar policy proposals. So if you are looking to attract people, you want to find them in a venue now before you make it to the social, now would be the time to say I’m interested in working on a policy and people find me. Yes, center front.

John Springer: John Springer, Inland Telephone, ARIN AC. The open mic strikes me as a good place to begin jaw‑jacking about some of Leslie’s points. However, as Milton pointed out, I don’t think her slide deck is available yet.

John Curran: We’ll get that. It should be on the agenda. Should be on the agenda page for the meeting. But we’ll double‑check that now. If you go to the link on the right‑hand side, there’s a link to agenda and there’s a link to presentations. Yes, you got it? Yes, far left.

Bill Darte: Bill Darte on the ARIN Advisory Council. Just wanted to remind folks who may be first timers at the first meeting. The Advisory Council and probably almost everybody else participating in this room could help you understand and interpret things perhaps either in the process, the policy, or even in technical issues if those were going over your head or whatever. I heard some comments about that earlier, that people didn’t feel like they were getting it all. We’re all here ready to help anybody that needs it.

John Curran: Okay. Microphones remain open. Remote microphones are open. While people are thinking about any ‑‑ go ahead, Dave.

Dave Barger: Dave Barger, AT&T. Something totally unrelated to what we’ve talked about, but I’m just curious, is there anyone in the room who has received 172/8 address space from ARIN besides me?

John Curran: A few of them.

Dave Barger: The reason for asking is we have a /12, 172.0/12, and running into a lot of problems with content providers blocking the entire /8, and just getting an increasing number of calls from our customers and complaints, and obviously this is a problem on the far end, you know, with the content provider or hosting service or whatever.

But I’m just curious if there’s anybody has some interest in talking about how you’re working on the problem, how you’re solving it on behalf of your customers, that kind of thing. And I want to thank John and the staff for putting up a notice on the ARIN website about the proper filtering of 172. But continues to be a problem. And I’m just looking for other ways to get information out to those content providers or suggestions on maybe how we can handle the customer experience.

John Curran: Microphones open. You have Owen behind you and then ‑‑ go ahead.

Owen DeLong: Owen DeLong, Hurricane Electric. Let this be a notice to anybody who hasn’t figured it out yet: v4 is going get harder and harder; v6 is the solution.

John Curran: Thank you, Owen. Should have predicted that. Far mic.

Kevin Blumberg: Kevin Blumberg. We had an issue where it was just being blocked, and I know that at the time there was a lot of work by a lot of people, including the RIRs, in terms of getting it cleaned up. And that took a long time. That space was useless for I would say probably 18 months before things really got cleaned up.

I’m unfortunately not surprised 172 is suffering from this. And we’re at the bottom of the well. It’s the dirty gas at the bottom. It’s all over the place. I think that unfortunately at some point these filters are going to have to get turned off across the Board. It’s not going to be just about 172 or about 69 from the past. It will become impossible to deal with these filters. They have to go. But I don’t have a solution, and I don’t know if the RIRs are pushing that agenda in terms of trying to help with cleaning it up. Maybe that’s the question for the gentleman at the front.

John Curran: I will say that we did ‑‑ I did specifically ‑‑ we did outreach not only on the website but contacting a number of people who maintain filter lists and reminding them what reserve space is and isn’t. But there’s a lot of people who generate filter lists for other people. And it’s not just ‑‑ in some cases it’s not just the hosting company that’s doing anything wrong, they’ve picked up a filter list from someone and they’re like, oh, this is the one my buddy used for his ISP and it works great. And so unfortunately it’s very hard to change those. Those get deployed in fixed form and don’t always get updated. Center front.

Cathy Aronson: Cathy Aronson, ARIN AC. I just feel the need to say this, but I believe that ARIN doesn’t provide global routability for the address block that you get from ARIN. And as the first recipient of a piece of /net24/8, whenever millions of years ago that was, that wasn’t globally routed for quite some time either. So I don’t know ‑‑ I just ‑‑ it’s not guaranteed and…

John Curran: We should mention to people that these remnants are being issued and that people should pay attention to their filter lists, and that’s something that the people in the room can help talking to your customers or talking to other people in the industry. But I don’t know a systematic way of getting bad configuration information flushed out. Remote participant?

Robert Seastrom: This is not a remote participant. It’s a comment from me, Rob Seastrom, ARIN Advisory Council, Time Warner Cable, and in my personal capacity an LRSA signatory, which means that I have very old resources that predate the formation of ARIN.

And since the gentleman from AT&T brought the question up, you can probably imagine where I’m going with this, I am periodically advised by well‑meaning tech support people that the reason I cannot get to my 192.148 Provider Independent space is that all of 192 is private space. And the problem is that the people who go to the outreach things are not the people that we need to reach. That’s the crux of a lot of problems we have for routability, security, all sorts of issues that we try to track down. So if you have any sort of light bulb, some moment of revelation or clarity in how we reach the people who are not being reached, that, I think, is sort of the crux of the problem.

John Curran: Okay. Microphones are open. Center front.

Jason Schiller: Jason Schiller, Google. My personal experience having previously worked at a transit provider is that there’s really no way to reach these people. The best way to get space like this cleaned up is to put it in service and put something important on it. And eventually people will want to reach it and eventually it won’t get cleaned up. And, I’m sorry, it sucks until that happens.

John Curran: So www.google.com. Should we have people send you A records? Okay. Center front.

Heather Schiller: Hey, guess what, AT&T, you’re important. That’s part of why you got here.

John Curran: Okay. We’re still a little early. I’m actually going to slip in another presentation because that will help get our discussion going on open mic after the break. Our break is in about ten minutes. Let me bring you an update on transfers at ARIN.

Milton Mueller: I don’t know how appropriate this is, but a lot of people are calling for a moment of silence at 2:50 in honor of the marathon bombings.

John Curran: That’s a good idea. We’re going to have a moment of silence starting now.

(Moment of silence.)

John Curran: Thank you. In consideration of the aftermath of the Boston offense. So we’re in open mic. The microphones remain open for comments on any of the policy matters discussed. I ask that you not discuss the policy proposals coming up on the docket tomorrow. We’ll have an open mic for that, too. But certainly anything else, feel free. Microphones are open. Any policy matters? Anyone want to revisit past topics of the day? Anything on the policy experience report?

Cathy Aronson: I’m sorry, Cathy Aronson, I had to answer something urgent.
Jason and I were just having a fabulous conversation about RFC 2050bis and how the new version, how exciting that it is, weaves out all those things like stewardship and needs basis and all those things that we hold near and dear.
And so we were discussing where those might reside since they don’t currently if that passes reside anywhere. And the community’s thoughts on where we might make them reside or if we care.

John Curran: Have you looked in the new PDP, the ARIN Policy Development Process?

Cathy Aronson: But that’s not all the RIRs, right?

John Curran: That’s probably true. But I think if you look in the new PDP at the beginning, you’ll find requirements for Internet resource policy. It actually has some of those goals that we’ve seen historically in RFC 2050. When you ask for the ARIN region, I can reference PDP, which you folks considered and vote adopted and all of that. But with respect to the IETF, the ‑‑ so RFC 2050 is 15 years old, I’m thinking.

Cathy Aronson: But it’s super awesome.

John Curran: 16 years old.

(Laughter.)

John Curran: And a number of people have thought it needed to be heavily revised. There was an effort to do that in early 2000 which some IETF efforts don’t achieve liftoff ‑‑ I guess achieve liftoff but not orbit. And that was one of them. And actually there’s recently been a draft submitted to actually have RFC 2050 declared historic because of the amount of inaccurate information in it.
Now, the inaccurate information we kind of know because it’s been overtaken by events.

The events were that RFC 2050 has a snapshot of the address assignment and allocation policies as of 1997, and since that time we’ve had some changes, like ARIN as a regional registry, LACNIC, AFRINIC, ICANN, the formation of the registry system as an organized component under the ASO of ICANN, global policies, and all the changes in all the regions. So rather than having a 15‑year‑old snapshot lying around, a group of us finally got together ‑‑ myself, David Conrad, Russ Housley, and Geoff Huston ‑‑ and did RFC 2050bis which contains all the things we knew to be true.

So there is a lot of history and a lot of description of the structure that moved over. It does not contain any address policy. And it also doesn’t contain any principles or mandates from the IETF on the Internet system. It does say, however, that there may be technical constraints from the IETF on how we use address space. And if they give those to us, we will consider them in our policy making.

Now, the reason we didn’t enshrine any in the RFC 2050bis is we frankly don’t know what the IETF thinks the current technical constraints are. We do know that accuracy is important for being able to operate the network and law enforcement, and there’s a reference to Whois and accuracy. We know that they have told us that we need to exercise some form of management of the free pool or our pool, our allocation pool, because obviously if we gave everyone a /14 of IPv6 tomorrow, they might not give us a new allocation the next day if we’re not somehow responsible in the management of the space.

So we put some very lightweight items in the RFC 2050bis and we didn’t take any 15‑year‑old concepts and carry them over. But that doesn’t prevent the IETF from doing a BCP on any of those and providing guidance to the registries which the registries will have to consider in their Policy Development Process.

Cathy Aronson: I guess the question at hand would be us asking you ‑‑ my guess is Jason and I asking you personally ‑‑ what your thoughts would be on the best place for us to have that information besides just the ARIN PDP, whether we would do a global policy and try to get all the regions to buy off as the IANA saying stewardship or whether you think an Internet Draft or ‑‑

John Curran: Three are possibilities. If you’re only concerned about the ARIN region, obviously revising the PDP for what makes requirements a policy handles it. If you’re thinking globally, a global policy would work. And then finally, if you think it’s a technical constraint, the IETF BCP. All of them are available.
I mean, anything that you think you want to do there you should do. I don’t know what the IETF thinks ‑‑ the agreement between the RIRs through ICANN to the IETF is in a document called RC 2860, which has ICANN doing critical Internet resource number management, protocols and parameters, domain names, and IP addresses.

But ICANN is a carve‑out where the IETF says, yeah, for name, for protocols and parameters you do it our way, our RFCs. For names and numbers, we kind of realize you might have policy constraints through your processes within ICANN. We’re, by the way, a process within ICANN in that context. So the IETFs acknowledge that there’s things that we do in making up policy that are beyond their purview, okay. You can make global policy if you want to put constraints in there. But you can also go to the IETF and you can say if this is technically important and needs to be adhered by all RIRs you can do a BCP and under the RFC 2050bis that’s supposed to be considered by all the RIRs.

I can’t enforce that, nor can the IETF, but we have a relationship where they let us manage numbers. Presumably there’s a quid pro quo where we listen to their good technical advice when it comes down. Do you have good technical advice they need to give us?

Cathy Aronson: I was a little terrified when several of them stood up at the microphone during Sally’s talk and suggested that we give each country its own huge big huge block of IPv6. Super awesome. So I don’t know. But it just seems like we should have some sort of written down‑ness of it.

John Curran: Do you think that the current principles that we use, for example, in our region should be a global policy as by all the RIRs? Doing a global policy in the RIR community is probably more successful than herding the group of IETF community into something that a lot of them don’t spend a lot of time with.

Cathy Aronson: Yeah. Okay. Thanks.

John Curran: Microphones remain open. Center rear.

Kevin Blumberg: Kevin Blumberg, The Wire, ARIN Advisory Council. Last year we had a policy in regards to TPIA, the Canadian problem, I guess you could call it at the time. And it was there to solve a problem, a jurisdictional issue, regulatory issue, whatever you want to call it, and the biggest concern of the community was, A: understanding what the problem was. And then once the community understood it, the bigger issue was how was it not going to be abused?

And recently we’ve seen on the PPML, and I believe also part of the Policy Experience Report, that there’s an issue with the smallest of the small, where with slow start as an ISP, you need to have a /23 to be able to justify that initial /22. And the problem is that if you can’t get that /23, because you’re in a rural location where your upstreams have said no, we’re done, we’re not giving out more, which is now starting to happen, you have no way to start. Forget about slow start, it’s no start.

So the question for the community is I see two ways to resolve it: The first way is to drop the /22 minimum to the same as what the end user is, which is /24 minimum. That’s one way of dealing with it. It’s still slow start, but it’s a much easier number in which to work with. Because you would need a /26 ‑‑ correct me if I’m wrong ‑‑ at that point to be able to justify your initial /24. Which I think is still possible. The second way is to do something similar to what was done with the TPIA proposal, which was to prevent the gaming of the system. And so the way that was done was by not allowing transfers for X number of years and basically not allowing the monetization of the community in being generous in expanding on or making the needs assessment simpler.

So I guess my question for the community is: Is there a preference on either one? And if there is a preference on the no transfer, keep it simple, is that something that we should be expending to all new space that’s going out at this point so that we prevent people who do game the system, as was discussed, from monetizing unfairly in these end days? We know that it’s going to run out, but they shouldn’t profit from it over other people who could have actually used that space.

John Curran: Can I ask a question? You started out defining the slow start problem that small ISPs see, and that does interface with the transfer because of how policies are written. But it’s also true that it actually applies to us making ISP allocations. And so the question that comes up is: Is the concept of slow start, should it still be applicable in the days of run out, because if it weren’t for the slow start policy, there wouldn’t be a problem with transfers for the same need. Your proposal was a little different than removing it altogether.

Kevin Blumberg: I see it as two ways. You can keep slow start in and change the bit boundary to a /24, for example, to make slow start that much more accessible in run out. That has routing table implications, has a number of other implications, but I don’t know that at this point it matters in the grand scheme. Or you can take out slow start but prevent the abuse of that space. That’s really ‑‑ that’s really what ‑‑ the two ‑‑

John Curran: Got it. I didn’t catch that as the second part. So people who want to talk about this concept, come to the microphones. Yes, center front.

Owen DeLong: Owen DeLong, Hurricane Electric. I actually think that just dropping it to a /24 isn’t sufficient, much as I wish it were because it would make things a lot easier. But even the example that we have currently on the mailing list that kind of spurred this discussion has stated that he doesn’t have the ability to get enough from his upstreams to represent even so much as a /26.

So I am concerned that that would be actually inadequate because I suspect he’s not alone in his situation. I don’t know what the right answer is just yet. I’m still working on formulating that in my head. I kind of figured I would defer some of the thoughts on that to after this meeting because I wanted to focus on the things that are actually being discussed and happening at this meeting, more leading up to this meeting. And there’s only so much bandwidth.

But I would be very, very interested in getting further community feedback and looking for creative solutions to this problem. I think we do need to try and address it both for free pool and for transfer purposes. I don’t know whether we’ll be able to address it for free pool purposes fast enough that there is a free pool left when the addressing happens. But we should at least make an effort on this.

John Curran: Got it. Center front mic.

Jason Schiller: Jason Schiller, Google. The concern I have with regard to dropping the bit boundary for slow start is the impact it would have on the organizations that currently can justify larger amounts of address space and what it would do to their current slow start process. Well, would they have to start at /24 and then double to a /23 and then double to a /22?

Owen DeLong: If they’ve got more, they can justify more.

Jason Schiller: So the question is would the suggestion require all slow start to start at a /24, or would there be a way for slow start to also start at the larger boundary that it currently does.

Owen DeLong: Slow start ‑‑

John Curran: I’m not sure I understand it. Kevin, do you?

Kevin Blumberg: No. Jason, my understanding is if somebody has a /24 or /23 of space today from their upstream and they want to ask ARIN for a /22 based on whatever, that’s fine. The minimum is what we’re talking about addressing. But if you need more, I don’t see it as a problem.

Jason Schiller: My concern is if you’re on slow start and you miss your window and you drop back down to the smaller size, does that mean dropping down to a /24 and starting from there, whereas today it’s dropping down to, what, a /22?

John Curran: Oh, I see. You’re saying if you qualify but then you can’t qualify for the next growth.

Jason Schiller: I mean, circumstances overtake you. You don’t have time to roll out the space. You have a start and a stop, for whatever reason. Today you can come back for ‑‑ I guess it’s a /22.

John Curran: The additional allocation ‑‑ once you’ve gotten an allocation, it’s additional ISP policy for the next allocation.

Jason Schiller: Say, for example, an organization comes up and says I have a business plan that demonstrates I need a /16 in the next year. And they have no history with ARIN. So they get today a /22. So the /16, first of all, you’d divide it down into quarters. So that would be an /18 per quarter. But they’re still not going to get an /18 because they have no history. So they’ll start with ‑‑

John Curran: They’ll start with a /22. Presumably multi‑homed.

Jason Schiller: They could consume the /22 and then come back and get a /21 ‑‑

John Curran: Right.

Jason Schiller: ‑‑ and then come back and get a /20. And then let’s say they stall for some reason, they’re short of cash, they can’t get equipment deployed ‑‑

John Curran: Which means they have lots of IP addresses that they’re not using because they haven’t grown?

Jason Schiller: They missed their window. So you start back up, and they consume the rest of their space and they come back.

John Curran: When they consume the rest of their space, they can get another allocation.

Jason Schiller: But because you missed the window because it’s been a quarter now since they haven’t come back, they drop back down to a /22 or to the smaller size that they had recently gotten.

John Curran: I would have to look. Leslie, do you want to comment?

Jason Schiller: So the crux of my question is could we implement this change without impacting what size current organizations that currently apply for the larger blocks? That’s basically the crux of the question.

John Curran: Yes. There would need to be some care there to prevent an overlap with someone currently in the process. Is that what you’re saying?

Jason Schiller: Even organizations that are not currently in the process but would in the future qualify for the current process, are they now going to get penalized because they’ve dropped the boundary down, there’s that many more hoops to jump through.

Kevin Blumberg: Can I just ask a question. Is your preference then to have this as a separate version, leave it as is and have it as a separate cutout for the really small, small ‑‑ again, I’ll do the next ‑‑ ultra small ISP types?

Jason Schiller: I think that would be fine. Yes.

Kevin Blumberg: Thank you.

John Curran: Microphones remain open. Anyone else want to come up and talk about a topic regarding policy? Yes, center front.

John Springer: John Springer, Inland Telephone, ARIN AC. In our lunch table meetings it came to light that LACNIC has put a reserve in place for something similar to this. That sort of concept sort of resonates with me a little bit. I like the idea. So we know from our outreach that we’re not reaching everyone that we would like to reach because we continually hear from people that are like oh, wait, I just ‑‑ I don’t think it would be bad if we were to contemplate some phenomenon like a reserve to try and take into account the people that we are pretty sure that we’re going to be hearing from right along as this run out takes place. It’s good stewardship, I think.

John Curran: It’s inevitable after run out we’ll have a number of ISPs show up who say I did not know, I did not hear or I didn’t think it was ‑‑ more commonly it’s a little more nuanced: I knew it was coming; I didn’t mean you meant now, is probably what we’re going to have a lot of people showing up. At present we’ll be at depletion. There’s a wait list policy. They can wait. There’s the potential return of address space from IANA that could be matched up or returns from the community.

There’s reclamation that could also match people up. So it’s not inconceivable that someone who doesn’t hear is going to be disappointed, but it’s likely a lot will be disappointed in other regions they have instituted an austerity or last SIP policy with a reserve. We have not done that in this region. Certainly it’s something that could be considered. It needs to be considered in enough time to set aside the reserve, obviously.

Microphones remain open. If we don’t have anything else, I’m going to close it and go to closing announcements. Okay. I hope everyone have great discussions in the hallway and tonight at the social. Okay. So we are going to close today’s session. I thank you all. Round of applause for everyone putting up a day of address policy.

Closing Announcements and Adjournment

John Curran: I’d like to thank our sponsors. Network connectivity by LIME and webcast by Google. Thank you.

(Applause.)

John Curran: Tonight’s social is at Harbour Lights, 7:00 to 11:00. Buses will be out here at 6:00 p.m.; the last bus leaves at 7:00 p.m. You need your name badge. Very important. Okay? And bring your favorite tropical shirt. Return shuttle every 30 minutes starting at 8:00 p.m. until 11:00 p.m. You must be on the 11:00 p.m. or you are on your own.

Reminders and recap. Breakfast will start at 8:00 tomorrow. Meeting will start at 9:00. You can peek in the meeting materials online or in your agenda packets. We have a few more policies we’ll be talking about. Should be a good day. And that’s it. I’d like to thank everyone and I’ll see you tonight at the social.

(Applause.)

Network Sponsor

Webcast Sponsor