ARIN 37 Public Policy Meeting, Day 1 Transcript - Monday, 18 April 2016 [Archived]

Note: This transcript may contain errors due to errors in transcription or in formatting it for posting. Therefore, the material is presented only to assist you, and is not an authoritative representation of discussion at the meeting.

Opening and Announcements

John Curran: Okay. Welcome. I’m John Curran, President and CEO of ARIN. I’d like to welcome you to ARIN 37 in Montego Bay. Thank you, everyone. I’d like to point out who is here. Attendance, we have nine attendees from Canada, 56 from the United States, 48 from the Caribbean, 14 from outside the ARIN region, and 28 remote participants. So, good turnout. Glad to be here.

Our Board of Trustees is in full attendance – Paul Anderson, Vint Cerf, myself, Timothy Denton, Aaron Hughes, Bill Sandiford, and Bill Woodcock. These folks were elected, except for myself, these folks were elected by you. They help guide ARIN on its mission, provide the appropriate oversight of the organization.

We also have our ARIN Advisory Council in attendance, Dan Alexander and Vice Chair Kevin Blumberg. Where’s Kevin? Yes. And AC members stand. They’re all here in attendance. Thank you.

The ARIN Advisory Council aids in the Policy Development Process. They’re the ones who listen to you, help come up with proposals to change the policy process and help work them through the development process. They’re also elected. We elect five of them every year, and they’re the ones who do the heavy lifting in making sure the policies we use to operate are developed to meet the needs of the community.

We also have a number of guests from the other – we also have the NRO Number Council here. The NRO Number Council is the group that we have that’s responsible for working – three representatives from this region, three from the other four regions, 15 in total – they work within ICANN as the ASO, the Address Supporting Organization, Advisory Council which means they appoint two seats to the ICANN Board. They’re also responsible for coordination of global policy. Louie Lee, are you here? Yup, Louie, Jason Schiller and John Sweeting are the three members of the NRO Number Council.

Our RIR colleagues. We have a number of colleagues in attendance. AFRINIC, we have Alan and Seun. We have from LACNIC Sergio and Wardner; Adam from APNIC; and then from the RIPE NCC, Dmitry, Andrea, Andrew, and Philip. Round of applause for our RIR colleagues in attendance.

As folks are probably aware, it’s one registry. And so even though we have five different regions, we have to coordinate to make sure it stays one registry. It takes a bit of work.

The ARIN management team – myself, Nate, Cathy, Richard, Leslie, Michael, Erin, Susan, Mark and Val – are here. Management team, rise. Thank you. Very good.

Okay. So I’d like to welcome our 15 ARIN 37 Fellowship recipients. We have folks from all the sectors. So if they would please rise up if you’re a Fellow, please rise up. Thank you. So from Canada – round of applause – Andrew, Alyssa, Mary Anne, Michael, Kevin, from the Caribbean, Kevin, Gary, Trevor, Daledrey, Patrick, Margaret and Jerry; and then from the USA, Craig, Roger, Allison and Jose. These folks are coming for the first time, generally, some repeats, but mostly for the first time to learn about ARIN and bring information back to their community. They all have mentors from the staff or from AC members who are helping them through this process.

So big round of applause for our fellowships.

(Applause.)

Okay. So first-timers, folks who are new to ARIN attend often the ARIN at a Glance, the first-timer session we had yesterday. And they had an in-depth orientation to ARIN, met some of the ARIN representatives, learned about our services. And as always, we have a prize drawing for the first-timers who sat through that.

If you are someone who attended the ARIN at a Glance session and you filled out a survey, run it up now to Susan. We don’t have all of them. We know a few of you held on to yours. Run them up to Susan. There you go.

Don’t feel guilty. We understand. We’ve got one in the back. Our gentleman from Baltimore. Very good.

And now I’ll need someone to draw from that basket. I’ll choose someone at random. Owen, if you would come up.

Owen, if you would choose the winner of the prize drawing, thank you. This winner, someone who attended, one of the new, first-timer attendees, attended the ARIN at a Glance session will win a $100 ThinkGeek gift certificate, which is very nice. You go online.

It is Oshane Gordon. Did I pronounce that right? Are you here? Yes? O-s-h, Oshane Gordon?

Hmm. Well, Oshane Gooden. I will make sure we get this to him. I’m sure it’s just my pronunciation and they’re in the room. Very good.

Okay. I’d like to welcome the remote participants. We have remote participants, as I noted. They have access to the full meeting. They have a webcast. They have a live transcript, which reminds me – I’ll save time – on behalf of our happy scribe doing the transcript, speak slower than I am, because I tend to speak fast and they need to transcribe for the people remotely.

The remote folks have access to the downloadable meeting materials. There’s a chat room where they can go on record. They have a virtual microphone, which we’ll read if they produce a comment. And we also have a hands-up – they can be counted in the show of support for policy.

So they have full participation. If you can’t be at an ARIN meeting, please participate remotely. Even if it’s just for the particular policies you’re interested in, this helps us to have policies that meet your needs.

Okay. I’d like to thank our sponsors, network sponsor C&W Business and webcast sponsor Google.

(Applause.)

Sponsors play a huge role in getting our meetings successful. I don’t know if people understand, but our meetings require a bit of network connectivity and would tax almost any normal facility.

We need a network sponsor to bring in the bandwidth that this meeting requires and there’s – particularly when we travel, there’s not a lot of locations.

If you are interested in being a network sponsor, please let us know and we’ll work with you to get a meeting in a location that you can support. It’s very important. Right now we’re working on, oh, 2018. If anyone happens to want to be a network sponsor in the Miami area, for example, please find me. We could use a network sponsor.

Tonight’s social. We have a beach barbecue at Sunrise Beach tonight from 6:30 to 10:30. Your badge, your social badge is with your name badge in there. Is it in there? Yes, it’s in there. You have a social badge that you can pull out. Okay. Very good.

After our meeting is CaribNOG. Going to be starting Wednesday afternoon, running through Friday. And it’s in this room. And if you are interested in network operations in the Caribbean region, please register for CaribNOG. It should be a great session.

Some rules and reminders. You’re participating in our processes, and we have some expectations. And it’s really simple. We want to make sure everyone can have a chance to be spoken – everyone has a chance to speak and has a chance to be heard.

State your name and your affiliation when you come to the microphone. Please be respectful of others. There’s a list of courtesies in the program, if you have any questions. This is so that we can actually have a productive session. Pretty important stuff.

Okay. So today – today we’re going to have some reports in the morning and some policy sessions in the afternoon.

The morning is AC On-Docket Proposals, the work that they’ve been doing; our Regional Policy Development Report; a Policy Implementation and Experience Report, about number policy that’s been adopted and how well it’s done and feedback from staff; the Internet Number Resource Status Report, the status of numbers globally in all of the registries; a report from the IETF, the folks who bring us the wonderful standards that make the Internet run; and we’ll have an operational success story panel, the IPv6 panel.

I’d like to take a moment, however, before we jump on today’s agenda to welcome a special guest. We have someone here from the Ministry of Post and Telecom, Cecil. Let me do the introduction formally. Mr. Cecil McCain is from the Ministry of Science Energy and Technology. He’s the director of post and telecommunications in the ministry, and he provides technical and policy advice to the government of Jamaica on telecommunications, the postal sector, and information and communication technology-related matters. I’d like to offer a moment for Cecil to come up and provide some comments. Warm welcome for Cecil McCain. Thank you.

Cecil McCain: Thank you, John. I’ll be very brief this morning. I’d like to thank John and his team from ARIN for choosing Jamaica to have the 37th ARIN conference right here in Montego Bay. We look forward to the next time that you make a cycle. There are some other fantastic destinations here in Jamaica you can visit – Negril, Ocho Rios and Kingston. We look forward to you all coming back.

My task is to welcome you all here, welcome all the ARIN stakeholders, both present and those listening in remotely.

We thank you for joining us here at ARIN 37 in Montego Bay. We look forward to the lively discussions. We know that as a panel that is made up, of course, of geeks, we can be quite passionate about our positions, and so we look forward to the very lively discussions that are going to be taking place.

But despite the discussions, we have a saying, we always do in Jamaica, and I’ll start with – we all know Bobby McFerrin. He sang the song “Don’t Worry, Be Happy.” And for those of you being here in Jamaica for the first time, and from the Caribbean, you’re more familiar with Bob Marley, those “Three Little Birds” – who knows “Three Little BIrds?” Don’t worry, every little thing is gonna be all right. “Three Little Birds.” The song is “Three Little Birds.” Every little thing is gonna be all right. I’m sure you’re going to be hearing it tonight on the beach or somewhere. Someone’s going to be singing it for you.

But of course we’re most famously known for this phrase: Jamaica, no problem. So, of course, as we go through our lively discussions, remember this is Jamaica, so therefore no problem. Thank you very much.

John Curran: Very good, no problem. Let’s start right ahead. This afternoon we’re going to be doing some draft policies, we’ll have an update on Whois accuracy and we’ll have a software development update. You’ve already introduced the head table. We’ve been joined by Scott Leibrand at the end, who is going to be our jabber scribe who will help keep track of the remote room.

And so I’d like to start right in. The first item on the agenda is going to be the AC On-Docket Proposals Report, and I’m going to have Dan Alexander come up and give that.

AC On-Docket Proposals Report

Dan Alexander: Good morning, everyone. So we’re going to talk about a few proposals today and tomorrow, one of which is 2015-3, and this is to remove a 30-day utilization requirement in end-user policy. This proposal is actually in a recommended state. So what that means is based on the discussions here in its final review, it’s actually eligible for the AC to recommend it to the Board.

So we’re going to be discussing that this afternoon, and you’re going to help us determine if this is, in fact, good policy and all the requirements have been met and it’s able to move forward.

There’s also four other draft policies on the docket. 2015-2 we’re going to talk about this afternoon. 2015-7, -9, 2016-1, those will be talked about tomorrow. Your feedback is going to help the AC determine if these are able to advance, they must be fair and impartial, technically sound and supported by the community. These are some of the main criteria that the Advisory Council uses in review of the proposals. So your discussions will help determine whether or not these proposals should move forward or potentially be abandoned.

But for these four draft policies, one thing to note is they’re actually not eligible to move to a last call state at this time.

There’s also – during the lunch sessions today and tomorrow, there’s designated tables in the room that will have four different topics on them that if you would like to discuss those topics you can sit at these tables, one of which is anyone interested in joining the Advisory Council, you have a chance to sit down and talk to some of the AC members, see what it’s like, get your questions answered, and hopefully we can interest several other people in joining, helping serve on the Advisory Council.

The other three topics, one is whether or not there’s a different way to look at need. We often – for the past several meetings, we’re always debating who should get resources, who should be able to transfer resources. And we’re really interested in exploring other ways, if it’s possible to evaluate, what it really means to need these IP addresses.

The other topic is IPv6 for small organizations. Are there policies currently in place that are prohibitive or make things difficult for small organizations to obtain the IP addresses that they need to build their networks?

And the last one is there’s – the Board has passed a fee schedule that’s going to be implemented in July, and that changes the structure in how ARIN organizations are charged for the resources that they have.

And the Advisory Council is really interested in seeing if there’s any policies as a result of these changes that are coming up that should be made to better manage the address space.

One of the other reasons we also came up with some of these table topics is we’re trying something a little different this meeting in that tomorrow afternoon there’s a policy simplification session.

And the last three topics there are some of the main points that we’re going to be looking at when, now that the ARIN free pool has depleted, we look at this policy manual that has evolved over many years and has a lot of special circumstances incorporated and things to preserve, the free pool, we want – the Advisory Council wants to take a step back and look at how much of this really applies going forward and what changes could we make, so if we could potentially simplify the manual, making it easier to deal with, potentially bringing more people forward, getting their records in line, updating Whois.

In addition to these topics, there’s also the ability to have the breakout rooms. So if somebody has an idea for a proposal or wants to sit down and discuss with a couple of people an idea or an issue that they have with policy, you can reach out to any AC member, and we can arrange a separate room if you want a quiet place to talk.

And that’s what’s coming up. Thanks.

John Curran: Any questions for Dan? Any questions for Dan? No? Thank you, Dan.

(Applause.)

John Curran: Okay. Next up on the docket is our Regional Policy Development Report and Einar Bohlin will give that.

Regional PDP Report

Einar Bohlin: Thank you, John. My name is Einar Bohlin. I’m formerly the senior policy analyst at ARIN, and I’m currently the government affairs and public policy analyst, and this is the Regional PDP Report.

I’m going to talk about a couple of things. I’m going to talk about some trends and proposals that you can see at the various – at the five RIRs and give you a couple of highlights.

2011 saw at least 101 different proposals at the five RIRs. As you can see from this table, the biggest topic were numbers, v4 and v6 numbers. That was a big year with IANA exhaustion and proposals being written about the exhaustion, about how to deal with that, about soft landing, about – and transfers as well were proposals back then.

Last year, 2015, saw 41 proposals among the RIRs, and it looked like maybe that was a trend. However, we have 25 unique proposals being discussed right now at the five RIRs. That’s just the first third of this year. So it looks like the number of proposals is going to go back up.

And I did a little something different in 2016. I pulled out and I made a new category of transfers. I also went back to 2015 and looked at how many proposals were on transfers last year. It’s interesting, there were nine proposals on the topic of transfers last year. And there are already 10 this year. So that looks like that is an – that will be an increasing curve, right?

So some highlights at the different regions. This first item on directory services, I think I mischaracterized it during a previous talk. The title of the proposal, and even though it was withdrawn, I wanted to close it out. The title was registration of detailed assignment information in Whois. So ultimately this has been withdrawn. However, it is kind of interesting. One of the implementations of CGN, or carrier grade NAT, is to give the same IP address to multiple customers. The way you differentiate the customers is by giving them a range of ports.

So initially I thought this was about actually putting those customer records in Whois or somehow registering them. That’s not what this was about. It was simply about putting what the port ranges you could expect to see in these IP ranges would be.

So, for example, if you were going to give 32 ports to your customers from a block of IPv4 space, there would be an indication that the port range size was 32.

And the purpose or the policy statement for this was to facilitate filtering. So if you’ve got some traffic coming from an IP address, you didn’t necessarily – and you were an ISP – you didn’t necessarily have to filter the entire IP address. You could target the port range and the IP address and maybe not hurt more people that are using that single IP address. So ultimately withdrawn.

Other thing to note – oh, question on –

Jason Schiller: Jason Schiller, Google, ASO AC. To clarify, this was not recording which set of ports belong to which customer?

Einar Bohlin: I’m sorry, it’s kind of hard to hear up here.

John Curran: Slower and clearer.

Jason Schiller: Jason Schiller, Google. So this policy was not attempting to document which set of ports belongs to which customer?

Einar Bohlin: Yes, that’s correct. It wasn’t about identifying individual customers, just about what port ranges you could expect in a block of IP space. Right.

Another highlight I have here is ASN policy. I think at all of the RIRs, ASN policy has been pretty static for 20 years. You have unique routing policy or multi-homed. It’s interesting, there’s a proposal that’s been adopted in the APNIC region which just makes it a little easier to get Autonomous System Number, and I happen to know that there’s more discussion about Autonomous System Numbers coming up today.

References. All of the RIRs have a landing page that shows you which proposals are in which state. They can be recently submitted, under discussion, advancing through the process, last call, soon to be implemented, abandoned, et cetera.

Everybody does a really good job of documenting that.

I’d also like to call out the Policy Comparison Overview, which is a document on the Number Resource Organization website.

It’s a high-level look at the policies at all five RIRs. So, if you, for example, wanted to see what the basic IPv6 assignment policy is or if each RIR had one, you can go to this document and find out that information.

I’ve personally found this document to be very useful. It’s updated quarterly. And that work is actually done by Adam Gosling, who is here from APNIC. I wanted to say thank you, Adam, for an excellent document and maintaining that document.

That’s my slides.

John Curran: Any questions for Einar on the report? No? Thank you, Einar.

(Applause.)

John Curran: Okay. Next up this morning we have the Policy Implementation and Experience Report. Richard Jimmerson will give it.

Policy Implementation and Experience Report

Richard Jimmerson: Thank you. I’m Richard Jimmerson with ARIN, CIO, currently the Interim Director of Registration Services as well. I’m here to give you the Policy Experience Report this morning.

The purpose of the Policy Experience Report is to review existing policies that have been set by you, the community, as the ARIN staff is the entity that implements the policies that you set.

We don’t comment on the merits of the policy proposals and the discussions that you have. It’s very clear that the only people in the community who cannot set policy inside the region is the ARIN staff. But over time the community has asked us to give this Policy Implementation and Experience Report to share with you the things that we’ve seen from the customers who are making the requests for the resources.

So what we’ll do is we’ll go over anything that appears to be ambiguous for the customers inside the policy text. Anything that might be inconsistent for them, or there might be gaps of effectiveness and those type of things. It can also identify areas where newer or modified policy may be needed. And it does look at operational experience that we’re hearing from customers in relation to the policies that have been passed and the feedback that comes from them.

We hear feedback from them on a daily basis, and we like to share that information with you today.

So we provide this feedback to the community and make any recommendations where appropriate.

So what you’ll find in the four that we’re bringing here today, we have NRPM 5 for AS number policy. And the other three are transfer related. That probably is not a surprise to anyone in the room.

We don’t have specific recommendations for all of these. And I do want to note that we’re bringing these to you because these are the items that we’re receiving the most friction from in communicating with customers over the last six months.

But the policy set that’s in place today we’re finding has effectively brought us through depletion in September of last year and has helped us through in the transition to the transfer phase of Registration Services that we’re in now and that really what’s there, you guys have protected everything that we’ve needed.

There’s been times when we’ve had difficulty and we’ve had to sit down as a team and evaluate something. We’ll sit down with Mr. Curran and do that, and we’ll find that you guys thought about that through the policy process over the years.

And what we needed was right there in the policy manual. But with that, we do have a few items we’d like to discuss.

One of them is AS number policy. The existing criteria you can see here, this existing criteria has been there since the 1990s. It basically states that organizations can receive an AS number, a public AS number unique from ARIN under unique routing policy if its policy differs from its border gateway peers or multi-homed site.

And that’s served us very well. However, there are a few request cases that may not exactly fit into those criteria. Some of them have – some customers have argued that they do and other customers have worked hard to conform to what they see inside the policy right now.

And it could be argued that some of these things fit under unique routing policy, but we wanted to bring them to you and get guidance from you just to be sure, rather than just making a decision on the fly ourselves going forward.

So some of those situations are – one is cloud services. Customers indicate that cloud service providers require that they have a public AS number to participate in that service. And also a distributed denial of service or disaster recovery purposes.

Organizations are setting up backup or parallel networks that aren’t continually in use that are only there in case they get attacked where they want to switch over to the new network.

Or in cases of disaster recovery, if there’s ever a problem inside that space. So I wanted to let you know that we are seeing those cases, and at the end of the presentation here I’m happy to hear any guidance that you might have as the community on how we should handle those.

But I want to tell you that what we’re doing today is we inform the requesting organization that the request doesn’t meet the criteria and restate the criteria from NRPM to them. Many modify the request to comply with the multi-homed criteria and produce agreements or letters from two providers to successfully complete the request process. Some have dropped their request. Some have come back and successfully shown us that it is unique, and we’ve accepted those. But that’s not typical that they do that. They usually try to go back and conform to the policy.

And the frequency of these requests have increased over the last year. We’re seeing somewhere between 5 to 10 percent is either for cloud services requirement or for disaster recovery or denial of service type reasons. And they’re becoming less atypical. So we’re seeing them more and more, and it’s becoming common. So I wanted to let you know about that.

The next one I wanted to talk to you about is NRPM 8.3. This is the policy that allows organizations to transfer address space where one organization has excess IPv4 and they want to act as a source to provide that to another organization who is acting as a specified recipient who needs the IPv4 space. The source, of course, we vet the source to make sure that the organization is authoritative before we allow them to release the space, and for the recipient we apply needs assessment in accordance with policies to that organization.

This is a scenario we have seen a couple times, and companies have come to us and indicated it’s an issue for them. So I wanted you to know about it.

So a company plans to transfer per NRPM 8.3 their existing Class B or /16 IPv6 address block. This is a sample scenario. So basically this is an organization that got a Class B back in the 1990s, and they’re a very small provider somewhere, and they really need this whole B. Maybe they’re only using a 24 or a 23 out of it.

And they have found someone. Someone has come to them and said, I want that Class B /16 address space, and I want the whole thing. And the person who is giving it up needs to keep a 24 of that or a 23 of that, but the person who is taking it from them says no, I want the whole thing. So that creates a situation where they have to come obtain their own 24 or their own 23 of IPv4 address space.

So the issue that they’re having is the organization can’t prequalify for a /24 if they currently hold a fully unused /16.

Although qualification is highly likely given existing usage, we can’t prequalify them for that because they currently hold the /16.

And the organizations are attempting to time their 8.3 recipient and their source tickets at the same time. And this is the problem that they’re having. So we understand, the people in this room probably very well understand and the ARIN staff very well understand that once they source that /16 to an organization, it’s going to be very easy for them to qualify for that 24 or 23 if they’re already utilizing that space. And it’s going to be quick and easy for them to do that.

But they have a concern, and their concern is that’s not a guarantee for them. What they’re trying to do is come in and get the prequalification. And what we’re telling them, we can’t give them a prequalification that’s conditional.

They’re nervous that if they release the 16 to the other organization that they will not later be able to get the 24 or the 23 that they need. We try to reassure them that they can do that, but it’s a trust issue and they have some concerns.

So I wanted you guys to know about that, and that’s actually happening today.

Some of them are pretty savvy. What they’ll do is they’ll come in and create a new organization ID, and they will request prequalification under that new organization ID so that it’s considered separate from the 16 under that organization. And they’ll move forward.

But others don’t realize that they can do that, and they might be sitting on the outside, not even coming to us, telling us about it. So we have no way to advise them. So I wanted to let you know about that.

Another one we have is 8.3 recipient complaints. We’re not necessarily asking the community to do anything about this. We just wanted to let you know that this is happening. And we want to let you know what we’re doing as the staff in these cases.

So the issue is: Customers are receiving IPv4 blocks through NRPM 8.3 transfers and then sometimes later they notice that the block that they received is being filtered as a result of being listed by spam mitigation providers. They’re on a block list somewhere and that space is just not working out for them.

So they’ll come back and they’ll make a complaint to ARIN. Well, what we tell them and we want the community to know is that ARIN staff verifies the authority of the NRPM 8.3 transfer sources and we conduct a need assessment for 8.3 transfer recipients. So for the source all we’re doing is making sure they’re the authoritative organization who can release that address space to the organization. They’re the registrant.

For the recipient we’re applying the needs assessment test as required by policy. We may notice that it’s on a block list, this space. We may notice that there’s something interesting about that space, but we do not notify anyone about that, because that is not our role. That’s not what we’ve been asked to do and we’re not doing it.

So I do want to let you know that staff does not review or advise 8.3 recipients of IPv4-block quality, and the quality of a given block is subjective based on the recipient and their intended use. We’re not basically warning people about the space that they’re receiving if we see something wrong with it, and wanted to let you know about that.

And the final one that I have here is NRPM 8.4. This is the transfer between regions, the sources in the ARIN region and the recipients in the RIPE or APNIC region are the reverse.

Some customers are attempting to transfer via NRPM 8.4 AS numbers. ARIN staff interprets NRPM Section 8.4 to only pertain to IPv4 blocks. So what we have here is ARIN staff is asking, are we properly interpreting NRPM 8.4 to not include AS numbers?

And also is it desired by the policy community AS numbers be transferrable via NRPM 8.4. And we would like to hear what you think about that.

So those are the four issues that we have, and the microphones are open and we’re happy to take any questions or comments that you have.

Charles Gucker: Charles Gucker, VMware. More clarification. When you’re talking about the cloud services, are you talking about cloud services end users or cloud service providers?

Richard Jimmerson: So we’re talking about users of a cloud service. So there’s a large organization out there, they have a cloud service that’s available. And this is a participant, someone who wants to participate, a customer of that cloud service who wants to participate in it.

And they’re being told by their cloud service provider that they will not accept a private AS number. And we’re not sure if that’s because they’re concerned about collision and the large number of participants that they have inside of that or if there’s another reason.

And we’ve actually seen in the documentation from some of the larger cloud service providers that they require that their customer use a publicly assigned AS number for that service. But it doesn’t really provide an explanation as to why.

And the customers are coming to us with that.

Owen DeLong: Owen DeLong, Akamai, ARIN AC. I think that each of those is a case of a unique routing policy and I’d like to see perhaps guidance given to staff that they explain that concept to the applicant and go ahead and process the request rather than saying, well, you’re not multi-homed, go away, which I’ve seen be basically the feedback some of the applicants have gotten, and then I had to explain to them the concept of unique routing policy and tell them how to resubmit their paperwork.

So I think that we can make the process friendlier without needing any changes in policy. The cloud service providers do have legitimate reasons. Having been on the other side of that somewhat, there’s a number of different issues that come up when you start getting 20 or 30 or 50 or 100 customers all trying to peer with you using a private AS number, and you’re having to advertise those further out to the Internet and strip off private ASs, and then you get entertaining loops between your customers and all kinds of other fun things.

It’s really a bad scene if you’re trying to run a cloud service and peering with a bunch of customers on private AS numbers. It just leads to all kinds of trouble you don’t want, not just the issue of collision.

So I did want to address a few of the other topics, but John seems anxious to talk, so I’ll defer to him.

John Curran: We’re happy to change how we respond to these atypical requests. But I guess I’m trying to seek clarification. Do you believe that these requests qualify under the policy and were implemented incorrectly?

Owen DeLong: Yes.

John Curran: So if that’s the case, I would love to hear clarity from that. I’ll take it from the AC as a consensus point and we’ll refresh the implementation.

But the wording of the policy and the history of it doesn’t necessarily make that clear. And so we’ve looked at this pretty hard and the language of the policy as written wouldn’t support what you just said. You don’t need to change policy, but let’s have the AC tell me clearly we made a mistake here.

Owen DeLong: I believe it does meet the letter of what’s written because they’re advertising a different set of networks to their upstream cloud service provider than what are advertised in general by their cloud service provider. They therefore do have a unique routing policy even though they’re not multi-homed.

John Curran: We’ll look at that.

Owen DeLong: Okay. The 8.3 we got a block that was owned by spammers complaints, yeah, too bad, so bad. Do your due diligence before buying, caveat emptor. The 8.4, no, you shouldn’t be transferring ASNs, that’s clearly not what the policy says you’re supposed to do and you’re doing exactly the right thing.

Richard Jimmerson: Thank you for those comments. Back microphone.

Jason Schiller: Jason Schiller, Google, NRO NC. If you could go back to the last set of slides about ASNs. I think in the second case where it’s disaster recovery, that’s clearly a discrete network, clearly they’re trying intentionally to build a parallel network that’s diverse, that has no single points of common failure. They’re clearly trying to set up a discrete, separate network. And I think that that should definitely clearly fit in the definition of a discrete routing requirement.

In the first case, if the cloud provider requires an ASN, I think, it’s best practice to not use a private ASN, because if there is another organization downstream that’s responsible for the routing, that should be clear to the rest of the routing system.

And if it’s a private ASN, that would be stripped at the EVGB boundary and it would look like the upstream provider is in control of those announcements and responsible if something bad is happening, say, like a route is flapping.

What’s not clear to me is why the cloud provider’s requiring an ASN at all. And I would love to hear from cloud providers why that’s needed. But certainly if there’s a good case for that, I would say that it should also certainly fit in the requirements.

On the second one about blocks which are blacklisted, I’d just like to say to the community, you’re welcome, and I’m saying that on behalf of all the large organizations that, over the years, when ARIN had flexibility for choosing which block to assign to a customer, they typically gave the dirty, messy ones to the large organizations. And we worked through our legal departments and through our routing and putting important stuff on those blocks and making and it not reachable to get those blocks cleaned.

And I’m sorry that you’re now sharing in that pain. I wish you the best of luck.

(Laughter.)

And the final question, yeah, I don’t think ASNs need to be transferred. We’re not out of ASNs at this point. Really the only case an ASN should move hands is if the network is moving hands, if it’s kind of an M&A type of arrangement. Thank you.

Richard Jimmerson: Thank you.

David Farmer: David Farmer, University of Minnesota, ARIN AC. On the last point here, part of the source of the confusion, I think, comes from the fact that APNIC’s ASN transfer policy also includes inter-RIR. We do not on our side.

We did discuss this and we ran into some technical issues about implementing the actual inter-RIR transfer of ASNs and decided to back away from it for the time being, but it’s probably something we should consider or at least help APNIC help their customers to realize that we don’t catch those transfer requests. And I’ll just leave it at that.

Richard Jimmerson: Thank you very much.

Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. I believe we had the 8.4 discussion already, and I believe paraphrasing a gentleman from APNIC, it was, we put it in because we thought the ARIN community would want it. But when we discussed from a technical point of view and the merits point of view as a community the last time, it was, this is a really bad idea because of a number of logistical and whatever and it wasn’t worth doing, given the vast number of 4-byte AS’s that are available to the community. I do remember that.

In terms of one of the issues, well, two things. One, spam complaints. My only concern is you’re saying ARIN has data and is opting not to provide that data at all. So I guess that’s the question. If you’re collecting information, you have the information, you see the information – not putting a spin on it, but just giving the blank or the black and white of the data that you have, is that better than holding data that you then – I guess it’s more of, A, a legal and more a moral question. If you have the data, why aren’t you providing it, even in just black and white without –

Richard Jimmerson: And for clarity, you’re speaking to this on the screen right now, “8.3: Recipient Complaints”?

Kevin Blumberg: Yes.

John Curran: So we have some data. Our data is neither exhaustive nor complete. And so it’s very difficult to say what we’re providing is useful. If we say we don’t see an impairment to a block, it might very well be impaired.

If we say we see a block is impaired, it might very well be not. So it puts us in a very difficult situation. And the implication of providing that data even though we can sit here and completely disclaim it to someone requesting address space, they’re going to have assumptions about what they hear from ARIN as authoritative. And so we just need to be extremely careful.

Kevin Blumberg: Based on that, I guess Mr. Schiller’s response probably holds true.

Vint Cerf: Vint Cerf from Google. Couple of thoughts. The first one is whether notification of the assignment of a block is in some way helpful to parties who are known to be managing block tables.

Do we do any kind of notification, or do we tell them they can look on a regular basis at new assignments?

Richard Jimmerson: Sometimes it does happen that the customer themselves will contact one of these spam mitigation providers and let them know I’m a new registrant and that organization will contact ARIN and ask for verification that that’s the case, and we will tell them yes, it is the case that we have recently transferred that from one party to another party and we’ll give them that information.

And sometimes they have lifted it. Other times they’ve had issues because, and I do want to mention this, is that some organizations who are using their IPv4 address space to do activities that would get them on a block list, they have found that for 500 US dollars they can transfer the address space from the entity that’s on the block list to a new entity that is still them, contact the spam mitigation provider, let them know that, hey, I just got this space and I’m being harmed by it, and they’ll contact ARIN. We’ll tell them yes, it’s a new registrant and there was a transfer, and then they’ll continue with their normal activities. So this is why we can’t have nice things applies.

Vint Cerf: So if you permit at the very least a simple notification of the transfer, seems like it’s something that we could do voluntarily, even if the interpretation is going to vary.

Richard Jimmerson: Yes, sir.

John Curran: And we do confirm, when asked, if they come to us. Most of the responsible ones follow our issued reports, our daily reports of addresses that are issued and transferred. And some of them have no problem. But they’re also concerned with that very case where if three spammers all transfer A to B, B to C, C to A, everyone’s happy and we all have clean addresses.

This is a situation where the historical practice of blocking an IP address block was predicated upon the fact that these weren’t being moved around.

Vint Cerf: I want to get back in the queue, but you have people waiting.

Chris Woodfield: Chris Woodfield, Twitter. I’m curious regarding the whole, the black listing issue. Has an explicit lack of warranty for the quality of IPv4 space ever been considered as part of ARIN policy?

John Curran: ARIN’s responsible for providing unique address blocks, and that includes handling the transfers of those rights between parties. The usage of an address block, the appearance of an address block on someone’s filter list of any type of filter isn’t in ARIN’s control. Now, it could be. You could all turn around and contractually say I want ARIN to handle this, and I give ARIN the right to control what I put in my filter list and I will enforce that.

But that would require a different world than we’re in, because right now we’re just a registry.

Chris Woodfield: You know that; I know that. The question I have: Has it ever been considered to explicitly state in the policy that ARIN does not make any warranty as to whether or not the space is going to be filtered by anybody.

John Curran: We tell people that when we assign the address to them, the information, we tell them this block’s been transferred, we can’t talk about its pedigree, we don’t know.

But, again, that doesn’t prevent them from coming back when they discover it’s a problem.

This is – I’m not saying it’s an intractable problem, but to the extent there are block lists operating on the Internet, those are operating in a time that presumed different assumptions about address space.

Chris Woodfield: Understood.

Richard Jimmerson: Front microphone.

Owen DeLong: Owen DeLong, ARIN AC. You mentioned a scenario where A to B, B to C, C to A, given the hold-downs that are in 8.2 – 8.3, rather, for the time between being a recipient and being a provider, shouldn’t that be not possible?

John Curran: It doesn’t have to be as direct. A company finds its address list blocked. Its friendly subsidiary or an unaffiliated – we can’t see it’s affiliated – the same parties form a new corporation, and they end up getting address space from the prior one doing a transfer.

When that happens, there’s no way for us to know legally that it’s the same spamming company under another name. When that happens and the transfer appears, it looks like just a transfer to a new organization.

So anything we do to encourage the removal of that from a block list could easily be reenabling a spammer.

Now, the fact that the same principals have now received address space under a new company name, well, yeah, there’s a hold-down, but they can always form another company and do it again. You can get a ring of these going that exceeds the time-out and the hold-downs.

Richard Jimmerson: I would like to add typically what we’ll see they’ll do they’ll come from a 16 and they’ll dole out 24s or 23s at a time. We understand it, we respect the 12-month lockout on the recycling, but they’re doing it in small pieces.

Owen DeLong: Got it. Okay. There was one issue I forgot to address. The transfer tie-up where they’re trying to unload a 16 and pick up a 23, yeah, that’s going to – that’s going to require some thought, but I think that the solution is probably to enable some sort of escrowed transaction with ARIN acting as the escrow agent where the two blocks come in and then they leave at the same time.

Richard Jimmerson: Thank you. And, Vint, I think you were next in line.

Vint Cerf: I wasn’t keeping that close track. I was very interested in this problem as someone with a /16 trying to transfer it but needing a /24 in order to continue operation.

Is there any – already any kind of provision for a sort of an escrow arrangement where they transfer the /16 to ARIN, for example, and ARIN in exchange for that transfers the /24 and then the 16 goes to the designated party?

John Curran: So there are escrow parties operating in the IP address space range. They’re used by people doing transfers. It’s common for funds to be escrowed. We don’t have people doing escrow of IP address blocks. It’s also true that escrow of IP address blocks doesn’t solve the problem when the policy constraints would prevent someone who received address space from doing a subsequent transfer. This is a case where even if you had an escrow agent, which is a just party that protects the transaction, the lock-downs on a party receiving addressing, doing a subsequent transfer, get in the way of that particular swap.

Vint Cerf: In that case, it sounds like there’s room for some rethinking of how to solve that particular problem.

Rob Seastrom: Rob Seastrom, ARIN AC. Could we flip back to the slide about the complaints about 8.3 transfers. I’m kind of fascinated that ARIN is getting any of these complaints at all.

It sort of harkens back to getting complaints to the Mailing List address policy from people who have mistaken ARIN for the Internet police.

There are three things that go along with an address block transfer. One of them I’ll call provenance, meaning the legitimacy of the transferor to offer it for transfer. That’s in ARIN’s wheelhouse. Pedigree, which John talked about before, which is is this on every RBL in the known universe because it’s inhabited by a nest of spammers? And then there’s merchantability or fitness for a purpose.

And it seems to me that this should be in the contract between the recipient and the broker. Now, this is a simple – if the customer wants a do-over on this and hand the address space back in some way, that maybe that’s something that ARIN could have something in space to facilitate, because, hey, there was a contract issue here with the broker.

But this seems to be, hey, you’re paying the broker some money as well as the transferor, the broker is doing the due diligence. It’s like buying a used car.

I’d like to see ARIN involved in this as little as humanly possible.

John Curran: We fully agree with that. That’s been our position.

I’ll note, though, be clear, the people who are doing transfers, when the rights to the address block transfer, when the registry is updated, the rights are transferred. What you’re talking about is the merchantability. Even in transfers that happen today of other things, such as buildings and property, often it’s a caveat emptor, the person receiving is responsible for doing their due diligence.

It doesn’t impact the transfer, and often it’s not even a condition of the transfer. It’s something that the buyer must beware.

And so I understand what you’re saying. I agree, in fact, the role you talk about for ARIN, but I’m not sure it would ever be a condition of transfer, it’s really a warning for someone to look at the suitability of whatever they’re requiring.

Rob Seastrom: Thank you.

Richard Jimmerson: Rear mic.

Alain Durand: Alain Durand, ICANN, speaking on my own behalf, not on ICANN. I wanted to follow up on a comment from Vint Cerf to publish when there’s a transfer so that people can know outside.

I would like to make the observation if you look at the statistics published by ARIN, there’s only the block that is being published as transfers. There’s a list of four blocks by date. While other RIRs are publishing more information, where it’s coming from, where it’s going to, what was the purchase date of allocation or assignment, and many other data.

So when you’re looking at this from the outside, look at the five RIRs, three of them have transferred now, but the three that transferred have different published statistics that doesn’t really help.

And any cooperation between the different RIRs to have a complete set of data will be certainly useful for those of us like me who are looking at that space.

John Curran: Agreed. At the end, people have to remember that the address block is only the entry in the registry. And there’s a lot of other information that is germane to its suitability for any purpose, including the information that’s whether it’s on spam lists, how it’s been routed in the past, et cetera. The registry’s role begins and ends with the address block, not its usage in the Internet.

Amy Potter: Hi, Amy Potter, Hilco Streambank. I broker these regularly. Just so everyone is aware, the standard process that people go through is that there’s a period of diligence prior to entering into the contract.

So people get a chance to review the space, check out block lists and satisfy themselves prior to paying any money, prior to signing a contract to go through that transfer. So if parties aren’t conducting sufficient diligence and find out after the case, I’m not sure how that’s any of ARIN’s responsibility.

John Curran: It is my understanding that people who are acquiring address block rights are always doing so with visibility into the block before they consummate a transaction. I don’t know of any place where people are putting down a price blind and getting the block assigned that it’s signed unseen.

So it should be capable for anyone to do due diligence on what they’re putting an offer in.

Alain Durand: Alain Durand again, responding to John. We just have transfers. But there’s most probably in the future being retransfers of those resources to other parties. And it will be difficult today with the data that is published to trace back those transfers to what was the original block.

And that’s why I would like to appeal to have more data made available.

Jason Schiller: Jason Schiller, Google. ASO AC. It’s not clear to me the level of due diligence you can actually do until you route the block and try to actually use it.

Certainly you can discover if it’s black listed on some well-known published lists. But who knows what crazy routing and filtering policies people have on the Internet.

Gosh, I’m sorry, somebody doesn’t like to route IPs that have the number 6 in them.

There’s not much you can tell until you actually try to route it and find out that someone is downstream from them and can’t reach you.

That being said, I still think ARIN’s role here is fairly limited. I did like R.S.’s suggestion of allowing them to do a do-over. If I was an organization that was approved for a /24 transfer within the next 24 months and I wait 12 months until I find the right block and get my contract sorted out and pay the money and I get the block and I complete the transfer and it’s registered to me and I go to use it and I go, “Oh, boy, I can’t use this,” I’m going to turn around and return the block to who I got it from saying please untransfer it to me and reinstitute my /24 preapproval for the remainder of the 12 months that’s left on that clock.

I would certainly be in support of that approach.

John Curran: So I’m not aware of a case where we’ve had someone request an untransfer of an address block. We understand, people understand that once we’ve transferred, it’s transferred. That they would be in a subsequent transfer mode.

And I think the thing that needs to be reminded is exactly what we talked about with due diligence. When you’ve been approved and you’re out there looking for an address block and you’re six months in and someone shows up and says I found one and here’s the price, it’s very much incumbent upon you before you consummate to pay attention to that.

NRPM – ARIN, in the Number Resource Policy meeting, we say we cannot provide or assure any form of routability in 1.3. We don’t control it.

So I’m not aware of parties that have come and said I’ve transferred it, it’s a turkey, I don’t want it now. But we have had people who have come back said I’ve transferred it, it’s a turkey, can I do anything about it. Our answer is caveat emptor. You acquired the block, and its usability was whatever it was when you acquired it.

Richard Jimmerson: Another comment from Dan.

Dan Alexander: Dan Alexander, ARIN AC. Just for clarification. On the 8.3 prequalification topic, in the last Policy Experience Report in October there was a scenario you laid out about market swapping where ISPs were trading networks and the one network wanted to give up space but needed something in replacement.

Is this along those lines, or is this distinctly a different scenario that we have to consider?

Richard Jimmerson: This is a distinctly different scenario. In the other case in the last policy report, it’s where two organizations wanted to swap with no net change on either side of the address space and we stated that we would consider those on a case-by-case basis and allow it unless we were told otherwise by the policy community not to do so.

But this does certainly have some differences, and I’d be glad to talk to you about them.

Kevin Blumberg: Kevin Blumberg. In regards to this, is it a situation where they’re looking for a new block? We’re going to give our /16 wholly? Or is it also a situation where they’re saying we’re going to give out and keep a 23 out of the 16?

Richard Jimmerson: So what this is, they have a 16. Somebody wants it. So they’re going to provide that through the market to them and they’re going to have it transferred at ARIN. They tell the person who is taking it from them, I’d like to keep a 24 out of this 16. The person receiving it says, no, I don’t want 255 24s, I want 256 of them. It’s the whole or nothing. Then they’re faced with having to go find a 24 themselves. That’s the issue here.

Because they’re not familiar with the policy community and they have less trust, perhaps, they don’t trust that after they release their 16 to the other party that they’ll be able to get the 24 back. And we convince them of that when they come and talk to us. But we’re concerned about the people who aren’t approaching us and talking to us about it.

John Curran: The scenario and case is anyone who has meaningful usage of that /16 will have no difficulty qualifying to obtain a 24 and transfer that from someone once they lose the 16 because they’ll have a large amount of – any meaningful usage of a 16 is going to be more than the requirements to meet a 24.

The problem is, while we know that and we all understand how this works, someone looks at the policies and says: I don’t know what happens if I transfer the 16 and I don’t qualify for the 24.

And while we know that to be a de minimis risk, for someone uninitiated to the policy process, they see how they could somehow be left without any address space.

Kevin Blumberg: The last question to that is right now are you saying that the qualification is a binary, 0 and 1, scenario, where you aren’t able to put caveats in so that things like that –

Richard Jimmerson: Correct. So when the organization comes to us, before they transfer the 16 and let it go, they come to ARIN and they say, you know what, can I prequalify – because we have that service – can I prequalify for a /24? And when they do that, we’re required as staff to look at the utilization of their previous blocks. We find that there’s a fully unused 16 with the exception of a 24 and they want to qualify for another 24 and we tell them no.

And then they say, well, can we put a condition on that? We’re going to transfer it later. And we tell them, unfortunately, no, we don’t currently do that. However, we assure them that if they do transfer the space they would be able to qualify for the 24.

Our concern is people may do this. We do accept a condition, and then they later never transfer the space but receive the new space.

So that is an issue for them.

John Curran: Right. Additionally, while we can tell them it’s our understanding based on what we’ve been told that you won’t have any problem, us saying that is not the same as a legal document which the prequalification that they want to have for purposes of consummating their other transaction.

And a lot of times there are more lawyers involved now than one might imagine. And they want to tie all the loose ends up before they do the transaction.

Our reassurances – our assurances that they obviously would qualify based on the utilization is not the same as performing a prequalification, and we can’t prequalify them as long as they’re registered with that 16. Simply we can’t.

Richard Jimmerson: Rear microphone.

Jason Schiller: Jason Schiller, Google, ASO AC. What is preventing ARIN from doing a prequalification contingent on the transfer of the /16, and given current utilization remains true once the 16 is transferred?

John Curran: You’re saying do we hypothetical prequalifications. We do not at present. We only do prequalifications based on asset holdings.

Jason Schiller: It’s not hypothetical. This is a renumbering event, and there are other cases where ARIN has given IP space in order to complete a renumbering event, at the conclusion of which they’re going to return some addresses and be efficiently utilized. For example, I’m an organization that has a /24 for my upstream provider. I’m now 86 percent utilized, and I’ve gone from 0 percent utilization to 86 percent in the last 45 days.

Can I please get a /23? Oh, and, by the way, I’m going to give the /24 back to my upstream.

John Curran: Right. That’s a situation where we understand all of the factors that apply when someone comes in. When someone’s coming in and they have a 16 and they indicate that they may release it but they’d like to be prequalified for a 24, we have never received any guidance from the community. This is not an amnesty process or an exchange process or a case where someone’s qualifying because of their existing subdelegation from an ISP, all of which were in NRPM.

We do qualifications based on what’s in NRPM. And specifically it notes that we can do that when someone has upstream allocation and use that for purposes of determining their need to issue address space. We don’t have any guidance in NRPM that says we can approve someone for a transfer based on their potential release or subsequent transfer to another party.

So if you’re saying we should be doing that, I get a little nervous because that opens the blocks to us doing a prequalifications. Well, what if I have an option contract? What if I have a lease of address space? What if I have – we don’t know where that would lead. If you want us to do prequalifications based on this, we’d prefer policy guidance.

Jason Schiller: Thank you.

Richard Jimmerson: Thank you.

John Curran: Thank you, Richard.

(Applause.)

John Curran: Okay. Next up we have Leslie Nobile. She’s going to give the Internet Number Resource Status Report.

Internet Number Resource Status Report

Leslie Nobile: Good, I can see. Good morning, everyone. So this is the Number Resource Organization Status Report, Internet Number Status Report. It’s basically the allocation and assignment history of the Internet resources in all five of the regions in a side-by-side format.

We update this quarterly. So this was just updated a couple of weeks ago. So it’s fairly recent data.

So this is the total IPv4 address space, the 256 /8s. If you look at the top, I’ll start with the green sort of slice that says not available. 35 /8s are in use by the technical community. They’re not available for IANA to issue to the RIRs because they are in use.

If you go left, you look at Central Registry, there’s 91 /8s there. The Central Registry was the pre-RIR space. It was basically space issued under US government contract – they were contracting with several different organizations – to issue that space. Most of the growth in the early days of the Internet was in the U.S. And so most of those 91 /8s were issued within the United States. This is what we call legacy space, the pre-RIR space.

If you go down a little further, the RIRs in total have received 130 /8s from the IANA, the Internet Assigned Numbers Authority. I think some of you heard John explain some of this yesterday.

IANA holds the global pool of address space and they issue /8s to the Regional Internet Registries for the regional pools.

So if you look here, APNIC on the left has received 45 /8s from the IANA in total; RIPE NCC has received 35; LACNIC has received nine; AfriNIC, five; and ARIN, 36.

And as you can see in red, IANA reserve says 0. IANA ran out of their /8s in the global pool in February of 2011. They have some bits and pieces that were returned to them by the RIRs, but there are no contiguous /8s remaining.

So if you look at the available IPv4 space in each of the five RIRs, starting on the left you can see AfriNIC in gray has the most remaining space with 1.8 /8s and still issuing under regular policies. In yellow is APNIC. They’re down to .59 /8s.

And both APNIC and RIPE have a policy that allows them to issue – when they hit their last /8, they basically call that depletion. And they instituted a policy that allows them to give a single /22 to each of their customers. Anybody coming in can get one single /22.

You’ll see ARIN in blue. It says zero. ARIN has no available space in our IPv4 pool. We have a couple of blocks reserved for specific policies. But as far as everyday issuing, ARIN has nothing to give out at this point.

LACNIC has .93 remaining and the RIPE NCC has .97 /8s.

This is an unmanageable chart. We’re going to work on this. I always say this, but we haven’t fixed it yet. Going back to 1999, this just shows the growth trends of IPv4.

The five RIRs issuing to their ISP customers, early on you can see it was – more of the growth was in the ARIN region, but that switched somewhere around 2002, 2003 and the APNIC region – the real growth was in APNIC region. And that just continued until they hit their last /8 in 2011.

This is IPv4 address space. This is actually the cumulativ e total. It’s the same chart from before, but it’s that cumulative total from 1999 through 2016. And you’ll see that RIPE NCC issued almost 35 /8s; ARIN, a little over 32; LACNIC, a little over 10; AfriNIC, a little over five; and the APNIC registry issued 45 /8s in that time period.

ASN assignments. This is total ASNs issued by the RIRs to their customers. These are 2-byte ASNs and 4-byte ASNs.

And early on ARIN was issuing most of the ASNs, and that’s because all of our customers pretty much are multi-homing and that’s why you would need an ASN. But somewhere around 2005, that trend changed and the RIPE NCC started issuing more of the ASNs, and they continue to do so today.

In talking with my RIR RIPE colleagues, they said they saw a huge growth trend, a real change in 2005 where more of their end-user customers started coming in asking for independent IPv4 space and an Autonomous System number, and that’s remained in place since – for about 11 years.

If you look at the cumulative total of all ASNs issued, ARIN has issued almost 29,000; AfriNIC, a little over 1,400; LACNIC, almost 6,000; APNIC, a little over 12,000; and the RIPE NCC, 33,576.

So this is a subset. This is the 4-byte ASN assignments. This is a subset of the previous two slides.

And what do I want to say about this one? This is kind of interesting. Early on we were all issuing – we were issuing 4-bytes by choice. We would offer a choice to our customers – do you want a 4-byte or 2-byte? But at some point we all realized we would all be running out.

So APNIC and RIPE and LACNIC all started issuing 4-byte ASNs by default. So if you requested one, if you requested an ASN, you immediately got a 4-byte ASN. And that’s why you can see more of the growth in the 4-bytes in those three regions.

Recently, and within the past year, ARIN and AfriNIC have switched over to issuing 4-byte ASNs by default as well because we’re all running out of 2-byte ASNs.

So you can see the numbers are evening out quite a bit more. We’re all issuing 4-bytes more often than 2-bytes.

This is a cumulative total. See what we’ve all issued. RIPE’s issued 6,600; LACNIC, 2,800; ARIN, 1,800; APNIC, 4,000; and AfriNIC 319.

This is the chart of the entire IPv6 address pool. It starts with a /0. And a /3 has been carved out of that space for use by the IANA as global unicast space. There’s 512 /12s in that /3. A single /12 is being used for miscellaneous purposes. I think there’s documentation and some other things that IANA is using that 12 for.

But five of those /12s were issued to the RIRs in October of 2006, and it’s really interesting because we’re all still issuing from our original /12. So for over, for about 10 years now we’re still issuing from a single /12, and none of us are actually ready to request additional space. So that pretty much tells you how large a /12 is.

If you look at IPv6 allocations from us to our ISP members, most of the growth has been within the RIPE region, as you can see in green, and followed by LACNIC, the LACNIC region.

Cumulative totals. RIPE has issued a little over 11,000; ARIN, almost 3,000; APNIC, 3,300; LACNIC, a little over 4,000; and AfriNIC, 452.

These are IPv6 assignments to end-user customers. We’ve all sort of had our end-user, IPv6 end-user assignment policies implemented at different times which sort of explains some of the earlier years where you only see the blue pie chart because ARIN was the first RIR to have an IPv6 assignment policy. But in recent years you can see that it’s really picked up in the RIPE region and continues to be pretty steady in the ARIN region.

These are the cumulative totals: RIPE 2,300; APNIC, 1,100; AfriNIC, 164; LACNIC, a little over 700; and ARIN, about 2,200 IPv6 assignments made since the inception of the policy in 2002.

This chart looks at the percentage of our members who have actually come in to get IPv6 address space. This has been sort of a successful growth trend. We started tracking it about five years ago and the numbers were very, very low.

So in the AfriNIC region, about 37 percent of their ISP numbers now have IPv6; in the APNIC region, a little over 47 percent; in the ARIN region I’m very happy to see we’re just about at 50 percent, so that’s a real change in our region; in the RIPE region, 84 percent of their customers, their ISP customers, have IPv6; and in LACNIC, a little over 75 percent, actually almost 76 percent.

And this is just the link to RIR statistics. You can see the raw data anywhere here. So that’s all I have. Are there any questions? Can I get the first mic?

Trevor Forrest: Trevor Forrest, 876 Solutions. You said in the RIPE regions you are noticing an increase in individual requests. Is there an indication as to what could be driving that?

Leslie Nobile: Maybe we can ask Andrea from the RIPE NCC to answer that question. He’s right here.

Andrea Cima: Hello. Andrea Cima from the RIPE NCC. I’d say over the years indeed we have seen a large increase in requests for AS numbers, and those were going hand in hand with requests for provider-independent address space. So not member organizations but other organizations, end-user organizations, often there would be like bank or other companies that wanted to be independent from the upstream provider with regards to resources. So they would request a block of IPv4 addresses, usually a small block and AS number to go with it to be fully independent.

As was in the past, we do not give provider-independent address blocks anymore since we have reached the last /8. But as you can see we have quite a large growth in membership and each member together with the /22 and a request for an AS number as well.

So the number of AS numbers issued is still quite large. We have about 180 AS numbers a month that we issue. Other than that, does this answer your question?

John Curran: Go to the mic for our remote participants.

Trevor Forrest: I was curious whether or not you had info as to, separate and apart from just the share independence, but what would have driven them to, I guess, need that independence from – from the – that’s kind of what I was curious about.

John Curran: Thank you.

Andrea Cima: What you could see in the region is that you would have many small organizations, many small ISPs as well. I think also for economical reasons, stability reasons, people would, for example, in certain parts of the RIPE region, of course, in Europe, would prefer to choose maybe to be multi-homed as organization with own address space and IS number, maybe even being multi-homed with connections which would cost less rather than having an upstream provider that would provide more reliability but would be more expensive as well.

So mostly I think economical reasons, political reasons, wanting to be independent.

Louie Lee: Louie Lee, Google Fiber, and also the chair of the ASO Address Council. This is a question about the 4-byte ASN. So some time ago there was a concern that ARIN customers were returning their 4-byte AS assignments and getting 2-byte AS assignments. And ARIN was possibly running into the issue of having too many AS’s to be able to request more ASNs from IANA.

How are we doing with that? Do we still have customers doing a lot of returns like that?

Leslie Nobile: Actually, we really had issues in the earlier days. Most people were coming back and trading their 4-bytes saying their ISPs couldn’t route the ASNs. Richard implemented the default, issuing 4-bytes by default last year, and I don’t believe we’re having very much of an issue, but he might want to address it.

Richard Jimmerson: We’re finding that organizations that don’t come in and specifically request a 2-byte AS number during the process that we provide a 4-byte AS number to are not coming back asking for a 2-byte afterwards. It’s very rare they’re doing it.

Those organizations that truly do know that yes, I specifically do want a 2-byte are very vocal about it at the very beginning of the process. We’re accommodating those as they come in.

Louie Lee: So will our inventory, does it feel like – I’m not going to commit you to any answer here – but does it feel like we will be able to ask for more AS blocks and still have some small amount of 2-byte for those that really need a 2-byte?

Richard Jimmerson: We submitted a request for additional AS numbers last year and got that satisfied. And in that we received 95 from the classic 2-byte range, and all the rest came from the regular 4-byte range.

We do not expect any subsequent request that we submit to the IANA for AS numbers. We’ll include any additional classic 2-byte range AS numbers for ARIN because they have run low on those, and we don’t expect that we will go back and request more before the other RIRs receive those.

However, one of the most commonly returned resource to ARIN through either nonpayment of fees or just a straight return is AS numbers. And it would seem that we’re getting more back through returns or reclamations than are being specifically requested by people during the review process for AS numbers.

So if we keep our current practice, we’re likely many years away from running into an issue of not having classic 2-byte range AS numbers available for those who specifically request them.

Louie Lee: Thank you, these are very useful answers for the community.

Leslie Nobile: I think there was a question here.

Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. Leslie, could you go to the v6 adoption slide near the end?

Leslie Nobile: Allocations or assignment?

Kevin Blumberg: Keep going. Percentage of members is specifically ISPs, not end users, in all regions. And all regions differentiate between ISPs and end users exactly the same way.

Leslie Nobile: Not exactly the same way, but this is mostly – this mostly consists of all ISPs in all five of the regions, yes.

Kevin Blumberg: I was trying to understand the accuracy. The second part was I believe in your last slide deck in Montreal, you differentiated v6 adoption rates by the size of networks in the ARIN region.

Do we have similar data for the other regions in terms of adoption based on size of organization?

Leslie Nobile: That was at a PPC. I don’t think so. But we can look at adding that to this presentation. That could be a good one, actually.

Kevin Blumberg: That would be really useful information. Thank you.

Leslie Nobile: We’ll look at that.

Jason Schiller: Jason Schiller, Google, ASO AC. Follow-up question from the previous topic. If we receive a lot of 2-byte ASNs back and the 2-byte ASN pool starts growing and growing and growing. And our default is to issue 4-byte and people are more likely to take a 4-byte, will we eventually get into a situation where we have no 4-byte ASNs left, we have a pool of 2-byte ASNs and we are unable to go back to IANA to get more space? And would we in that case then just start pulling by default from the 2-byte ASN until we’re in compliance and then go back and get more 4-byte?

John Curran: At present we’re not getting quantities of 2-byte ASNs back in any large quantity, that lower range of the ASN space. We have an inventory and we’re net negative each month. We’re allocating 6 to 10 per month who – parties specifically request such.

So I don’t expect it to be a problem. We have an inventory that looks like it would last five or so years at which point I hope that no one specifically wants to get a low-range ASN number. Hopefully those few people requesting it now, we won’t be hearing people similar demand.

Jason Schiller: Thank you.

Leslie Nobile: Thank you for your attention.

John Curran: Thank you.

(Applause.)

John Curran: So you’ll see on the agenda we now have a presentation, except we only have one minute before break. And as much as I have faith in Cathy’s ability to do a one-minute IETF report, I think it’s more prudent we’re going to put that later this afternoon. So we are going to take our break on time. And so it’s now 10:30. You have a half-hour break. I look forward to having everyone back here at 11:00 a.m. for the IPv6 panel, Operational Success Stories.

Our break is right outside. Right outside. So everyone enjoy your break. I’ll see you in 30 minutes back in here. Thank you.

(Break.)

John Curran: Owen, if you’ll come up. We’ll have a panel shortly. R.S. if your name is Charlie Gucker, please come forth.

Welcome back, everyone. Hopefully you enjoyed your break. Not enough time to make it to the beach but still a nice break.

IPv6 Panel - Operational Success Stories

John Curran: And so we have for the next hour we’re going to have the IPv6 panel on operational success stories. Should be interesting. I will have ARIN Board member Aaron Hughes, who is moderating the panel, and it should be informative for everyone. So at this point I’ll turn it over to you, Aaron.

Aaron Hughes: For those of you who don’t know me, I’m Aaron Hughes. I’m the CEO of 6connect and an ARIN Board member. And today we’re here to talk about IPv6 success stories. I tried to get a diverse group of panelists that range from large ISPs, small ISPs, enterprise, software, CDN services, DDOS mittgation.

So we’ve got quite a diverse crowd up here on the panel. To my left we have Andrew Dul, who is the network architect at EGATE Networks. Beyond Andrew we have Dan Alexander, who is an engineer at Comcast. And then we have Rob Seastrom, who is the chief architect at Time Warner Cable.

Rob Seastrom: I’ve been promoted. Principal engineer.

Aaron Hughes: Principle engineer, my apologies. And Owen DeLong, senior architect at Akamai. And on the other side of Scott, we’ve got Charles Gucker, who is a staff network engineer at VCloud Air VMware.

So perhaps we could start off with just a little brief introduction on your approaches to adopting v6 and a little bit of information about your v6 infrastructure respectively. We can start with you Andrew.

Andrew Dul: Thanks Aaron. So I’m the network architect for EGATE Networks right now and helping them deploy v6 as well as continue operating the legacy v4 network.

It’s a smaller network headquartered in Toronto. It’s a hybrid organization combining traditional Internet provider with hosting capabilities, voice services as well as doing managed network services. We provide connections of DSL of various flavors over cable, fiber line extensions and also hosting in the greater Toronto area and throughout Canada through some third-party, open-access requirements that are allowing us to be able to provision DSL across almost all the provinces in Canada.

For IPv6 network, we’re a fully dual stacked environment, dual stacked to upstream transit providers and we also peer dual stack over Torex. We’re not currently using any v6 transition technologies. It’s all dual stacked. We manage our IPv4 pool very conservatively and take an active approach to recycling as kind of best as possible.

We do use some RFC-1918 space for internal management networks and a few other areas. It’s a fairly simple network but we’re able to provide dual stack services to pretty much all our customers including DSL, cable and fiber services as well.

Not all our customers are taking advantage of v6 services, but we’re trying to introduce them to v6 as the opportunity presents itself. This is especially hard for a managed services enterprise customers who may not really understand v4 networking to start with, and v6 is just another thing for them to worry about.

While we have the ability to provision v6 almost everywhere, there is still some places we have some growing to do. Network monitoring and management is still done primarily on the v4 network and we still have some back-end systems that need to become v6 compatible. But I think one of the keys for success is having a good v6 addressing plan to make your deployments simple.

For example, we assigned a /48 to each site and then on occasion we embed the VLAN number inside our addressing blocks so it’s easy for people to find. So thank you.

Dan Alexander: Hello, Dan Alexander, I’m an engineer at Comcast. We’ve been working on v6 for quite a few years. And we’ve actually gained a lot of momentum.

About 25 percent of the traffic on our network is actually v6. We’ve got about 80 percent of our broadband customer base v6-enabled. We are operating in a native dual stack. We don’t or have not deployed carrier-grade NATs or large scale transition technologies.

We’ve tried to push native v6 to the customer wherever and however possible. It’s taken quite a long time to get there. And there was a lot of hand holding along the way with different projects.

But we took a very careful approach kind of piggybacking on other projects, other people’s momentum where if we were deploying a service to do Wi-Fi or something else, we kind of took that soft approach of, well, can you just get us this one feature now and can you get us this next feature in six months?

And we’ve been fortunate enough where we had the – we started early enough and had the runway allowable where we’ve now hit that kind of tipping point where our network is pretty much ready to go.

Rob Seastrom: Rob Seastrom, I’m principal engineer at Time Warner Cable. We’ve had native IPv6 in the core for many years. I want to say 2007, 2008 or something like that.

But the edge and the regional networks are always where it gets interesting to roll out IPv6. Our strategy has been to dual stack CPE and devices in the field as a transition to running them in IPv6-only mode wherever possible.

That’s been a very interesting proposition to get across to the vendors that, well, this dual stack thing is nice but what we’re actually looking for is the ability to get rid of having to have IPv4 addresses out there. It isn’t we’re just running a second protocol because we like running two protocols, that we want the end state to be no v4 addresses in the field.

So for things that are a self-contained environment, you’re probably not aware of this but your cable modem actually has multiple addresses associated with it, aside from the one that your router has, which is your high-speed data, customer-premises-equipment-sort-of address, which, of course, we want dual stacked so that you can talk to legacy IPv4 stuff as well as the grand future IPv6 stuff.

There’s some things that don’t need to talk to the rest of the world like the cable modem management address or the address for the phone line adapter in your cable modem.

And in those cases our strategy has been to move towards making those single stacked IPv6.

We did some work with the next generation set top box, where I was sadly not being able to – not able to claim that it was completely all IPv6, because there was still management interface for it to interface with the legacy management systems in the field.

But aside from that, all of its talking to cloud services and things like that, single stack IPv6.

We have a content distribution network for over the top video, which I’m pleased to say runs about 17 percent of its traffic as IPv6.

When one particular vendor, who I’m not going to name, but has a lot of customer-owned and managed devices that like to talk to the network fixes their IPv6 it’s probably going to double. We’ll probably be approaching 35% IPv6 on the content distribution network for OTTv video. Thank you.

Owen DeLong: I’m Owen DeLong. Akamai Technologies is a content delivery network among other things. So IPv6 has created some really interesting challenges and opportunities for us.

We decided to prioritize things based on delivering maximum value to our customers. So our first priority was to make it possible for customers even with IPv4-only origin servers to present a dual stack ability to reach their content.

We did that several years ago. We made it available to any customers that wanted it on an opt-in basis. We’re now discussing the possibility of making that the default unless the customer opts out.

And we’re making progress on that. We’ve started trials on IPv6 origin fetch, which is being able to fetch the original content into the CDN from the customer’s direct servers over IPv6.

We’ve got a couple of large customers that are pushing us relatively hard on that because they want to turn off v4 on their origin servers as soon as they can and make v4 our problem and not theirs.

And so we’re making a lot of progress with that. And we’re slowly starting to work v6 into our back-end systems and management systems so we can hopefully some day turn off v4 for the most part.

One of the very interesting capabilities, we’re a DNS-based CDN rather than an anycast-based CDN. So we have to actually try and identify where the customer is coming from in order to map them to the best server set based on their DNS resolver address being a proxy for who they are, except in the cases where we get EDNS client subnet information which is currently the exception rather than the rule.

One nice thing about IPv6 is we can actually, instead of having to map an IP address to a particular location in v4 where we’ve got a limited number of addresses in each location, we can actually map a particular request or a particular resolver request to a unique address for each request and then when we get the subsequent Web request on the cluster, we can actually know, okay, that resolver was acting for this client and we can actually start to build lists of clients that are associated with given resolvers in order to better tune and better optimize our service.

Charles Gucker: Charles Gucker, work for VMware, but more specifically a division of vCloud Air. We’re the cloud services provider.

Within Vmware, the philosophy of software development has been focused around software abstraction and network abstraction.

So with the IPv6 deployment, we do use it for an underlay within our backbone, but we have to start at the furthest underlay network and work our way up through all the different abstraction layers. That has proven to be a little frustrating at times, because certain customers at certain points in the abstraction layer haven’t expressed any interest in using v6 since a lot of our datacenters are utilized as extensions or the ability to relocate workloads from their on premise locations into the cloud.

And those workloads don’t have any dependencies on v6 since they’re all classified from the enterprise side as just being internal workloads. So there’s no residential exposure. There’s no user exposure. There’s no visibility outside of their little fiefdom.

So it’s a very interesting environment to be in.

Aaron Hughes: Thanks for the introductions. So what about your approach to transparency versus active? Can you talk about your respective companies implementing v6? Have you informed your customers?

Do you advertise that you’re actually utilizing v6? Do you advertise those features are available? Or are you more passive about it and just try to make the whole thing transparent so the customer never realizes that the transition’s happened?

Andrew Dul: I think it’s different for different customers, especially enterprise customers. I think they’re not wanting to have things turned on that they don’t know about.

Residential-type customers, it’s much easier to turn on new services where they can just go ahead and use it. So that’s a distinction I would make.

Aaron Hughes: Has anybody taken an active approach to advertising to their customers that they’re v6-enabled, v6-capable?

Rob Seastrom: I’ll see if I can speak to that. There are two customers: One is the people out in the wide world who are Time Warner Cable high speed customers, business customers, that sort of thing. Of course we have information about IPv6 on our Web pages.

But there’s also a huge sales task, and it’s a sales engineering task to the internal customer. The people who need to understand that there is this thing that will help them scale, will future-proof their internal product, you’re building a Web service thing that talks to this thing on people’s phones, a thing in a set top box.

There’s any number of things that you have a product owner internally and you have to go talk to them, say hi, I see you’re thinking about doing this.

You need to think about IPv6 for it. And talking to the datacenter teams, making IPv6 their default, not an exception that they only do when people specifically ask for it.

So I would say that there’s a – it does not magically happen that there’s a sales component of this inside the organization as well as outside.

Owen DeLong: So at Akamai, we’ve done a number of different things relatively actively. We’ve had a lot of internal activism going out to the various software development departments saying: If you’re building code that doesn’t support v6, you’re hurting the company. And so we’ve had pretty good success with that.

We’ve done a lot of outreach to our network partners, the way we’ve been deploying what we call ANPs or ANPIXs, where we push very hard to dual stack all of our connectivity on those, to the point we’ve actually had some providers deploy v6 somewhat in their network just to get us off their backs.

And then they discover oh, well, that wasn’t that hard and we can deploy it to our customers as well, which is kind of our goal in that.

We’ve also worked very hard with our sales teams and our sales engineering teams to make sure that they understand v6 and that they’re at least discussing that with the customers and customer prospects, trying to encourage them to dual stack their content on our platform.

Charles Gucker: From the engineering team, we try to do outreach to our sales folks, try to find customers, enterprise customers that utilize v6 to help prioritize further development up the stack for v6 availability.

And it’s frustrating sometimes because a lot of the customers are like, no, I want the really hot sexy VMotion with HA functionality over v6 functionality.

And a lot of the work that we do goes towards the base tenement of what we want to do in networking. And a lot of the customers, from my experience, are distracted by, well, I want the really pretty thing and not, well, what will make our lives a lot easier.

Aaron Hughes: Some years ago when we started talking about deployment of v6 and, really, more specifically, runout of v4, many benefits were mentioned around the space of, say, for example, longer term planning, some automation ability, securitiability, the nice long address so you can play with numbers.

I’ve heard some of you mention things like geolocation, VLAN identifiers, resolver locations. What kind of long-term benefits have you seen now having gone through implementations, in terms of automation and scale as it relates to v6?

Dan Alexander: For Comcast, one of the key things was the management gains that were offered by going to v6 rather than doing a lot of distributed systems or island deployments to be able to deploy a single, centralized management system and reach all devices on the network was a huge win for us.

And years ago we actually crossed a point where we have more devices that needed IP addresses than we had IP addresses. And we had to make that decision rather than to try and go out shopping and continue v4, it was just much more realistic to migrate to v6.

We’ve actually reached the point where we have several million devices out there on the network who have never seen a v4 address. They’ve come up native v6 from the start and they don’t have any v4 addresses.

Rob Seastrom: Another message from cable-land. We expend a huge amount of effort moving around IPv4 addresses, from CMTS to CMTS, the delicate balancing, people move from here to here, you do a CMTS split, you have to rebalance, stuff like that.

There is, by comparison, almost no activity going around, moving around IPv6 address blocks, because there is no extreme parsimonious mandate for conservation.

You choose an appropriate size. You put it on the device. It’s there for the life of the device.

Owen DeLong: So one of the things Akamai does is we provide a lot of SSL services. And it turns out that there are enough clients out there that still don’t support SNI that we have a lot of customers that want unique certificates.

And when you contemplate that we’ve got thousands of nodes around the world all serving thousands of SSL certificates, that adds up to quite a few IPv4 addresses around the world. And it’s not a trivial problem.

On the other hand, in v6, it’s a no-brainer and it doesn’t matter and it’s easy to do. So we’ve got that gain.

We’re working towards realizing some gains in the management arena, but since we deprioritized the management software upgrades necessary in order to meet the customer-facing requirements, those aren’t quite there yet.

But, overall, we expect to have a lot of benefits from v6, including the ones I mentioned earlier.

Charles Gucker: When we went out and built our under-LAN infrastructure, v6 allocations made it a lot easier for different locations and sites and we were able to properly plan long term.

But from a software orchestration and management functionality where the individual cloud services customers would have their own multi-tenancy environment, our address policy has nothing to do with their environment.

We don’t present any routing functionality unless they’re buying Internet services.

Aaron Hughes: I think it was Dan that mentioned back office as something that was a bit of a challenge. How have your respective organizations been with adapting tools, back office systems, sales systems, CRM, CRPs, billing systems, et cetera, to accommodate v6 transition?

Dan Alexander: I would say one of the benefits we had was a certain amount of scale that we could use to influence vendors, try and gain momentum there.

Beyond that, it was always people often run into the issue here of it’s always a matter of prioritization, convincing a vendor that they need this feature on the roadmap delivered in this version of code and then constantly fighting out over priorities versus other, what other customers may view as more beneficial feature sets.

That’s probably one of the biggest challenges that we always have encountered is just the prioritization of code delivery. And then what seems – we often talk here, it would be so easy if we just did this. Well, sometimes that takes nine versions of code and a year and a half to actually slip it into the roadmap and that’s one of the reasons why I’ve seen this stretch out so much longer than it has.

Andrew Dul: I would also say that working with your vendors can be challenging, because the level of familiarity with the protocol is much lower. And so you really have to be able to find the right engineers who know it and in some cases there may actually be no one in the organization that knows it and you have to spend lots of time debugging stuff yourself, which can be pretty frustrating, especially when your vendor isn’t supporting the software that they built for you.

But being able to have a success after going through the successful debugging and saying this is where the problem is, go and fix it, that can definitely feel like a good success story and also trying to find the right priority to make that happen.

So, that’s a challenge but I think it’s doable and going through the process also hopefully brings the vendors level of confidence with their code base up as well over time.

Charles Gucker: I echo those sentiments. Even internally, within the same company, it can be extremely frustrating to get the same products to do what you need it to do.

Aaron Hughes: Fair enough. So one of the things that I hear frequently when talking about v6 implementation, particularly with mixed sizes of companies and styles of companies, where do we find information on how we do things, what are the current best practices of doing these things, how do I interact with vendors, where do I start?

If you had to give advice to this room about your experience on how to move forward with v6 adoption, maybe you could describe some of your takeaways from your experience on what worked well and what didn’t.

Rob Seastrom: I’ll go first. I said earlier that it doesn’t just happen. You need to put someone in charge of it. You need to have somebody own that process.

My boss is Lee Howard, and he used to be on the ARIN Board, and that’s pretty much probably over half, maybe 75 percent of his deliverables for the year are focused around IPv6 adoption and curating information on it, managing working with PMO on rollout of cable modem management, curating a collection of employees who are resource people for IPv6 issues.

You sort of can’t just hope that things organically happen. It needs to have somebody who owns the process.

Owen DeLong: So at Akamai, we have kind of the same situation. We’ve got a guy named Erik Nygren who is responsible for a lot of our v6 leadership throughout the company. We also have a lot of internal documentation that’s been curated.

In terms of public resources, the best public resources I can point you to are the arinwikigetipv6.info. It’s not particularly well-curated, unfortunately, but it does have a lot of information, if you can dig for it. And most of the information on there is at least reasonably good once you do find it.

Another good resource is the O’Reilly Books by Silvia Hagen. She’s written some excellent resources.

Some of them are a little out of date at this point, but most of it is reasonably good best practice. But your absolute best resource is finding the people that you know that have done it and asking them, because they’re going to be able to tailor an answer to the way you ask your question and the environment that they know you’re dealing with.

And every environment is different. So just like there weren’t a lot of people there to tell you exactly how to do v4 when we first started doing v4, we’re in that space now with v6, it’s getting better as more people do more with it, but it’s still the early days.

Oluwaseun Ojedeji: My name is Oluwaseun Ojedeji, co-chair of AfriNIC policy. Thank you for this.

John Curran: You need to speak very slowly and very clearly. Up here the audio is a little hard with a fan behind us. So go very crisply.

Oluwaseun Ojedeji: This is Oluwaseun Ojedeji. Is that loud enough? Co-chair of AfriNIC Policy Networking Group.

I just wanted to get a view from each one of you. To what extent – I recognize that most of you are probably not in the procurement department.

But to what extent does your successes affect or require need for upgrade of device? That is, the physical hardware.

And I’d also like to know does the hardware that you then change which are now at end-of-life, what do you do with them?

Do you just ship them off to locations that are v4? For instance, like I come from Africa, and I think you wouldn’t be helping v4 deployment if you’re actually shipping those gears down to Africa, for instance.

So do you have a policy on what you do with your gears or your hardwares that are no longer just v4-compatible and long-term use.

Thank you.

Andrew Dul: Coming from a small organization, we don’t have a formal policy on equipment that goes other places. I would say that even equipment that’s five years-oldish, we’re running dual stack on, and the code base is pretty good.

There are some places where there’s work needed or certain parts of the network doesn’t reach that far. But in general we’ve squashed all of those at this point.

Dan Alexander: Sorry, I’m not familiar with our procedures as far as what we do with previous or decommissioned devices. So I can’t really answer that question. I’m not sure.

Rob Seastrom: I can’t answer that question from my day job, but I can answer that question for my avocation.

I run a small friends and family colo. And we have the luxury of being able to say, yeah, we’re not keeping anything around that doesn’t do IPv6, but part of that is – it’s twofold. One is we don’t have that much equipment to begin with so the total cost of upgrading everything is not likely to be prohibitive.

But another prong of that is that we leverage some very low-cost technologies that people who do rural networking are very familiar with, vendors who offer sub-$100 routers and switches and stuff and use those when appropriate.

It comes with its own set of support issues, of course. It’s not coming from Fortune 500 vendors.

At the same time, there’s a cost benefit tradeoff to that, and we actually find, because of the nature of our friends and family customer base, which you can imagine are people in this room kind of people, that they value IPv6 very much. And it would not due to offer my friends IPv4-only Internet.

Owen DeLong: In our case at Akamai, I don’t know what we do with used equipment. I have no idea. But I do know that we haven’t really had to replace any equipment just for the sake of v6. Everything we’ve been buying for many, many years now has been v6-capable.

And we tend to upgrade technology out of necessity for performance and other things on about a two- to three-year basis. So it’s actually been pretty hard in the last two to three years to buy large-scale equipment, equipment that operates at the scale we do, that doesn’t support v6, even if you went hunting for it. And we don’t look for that. We look for equipment that’s dual stacked.

Chris Whitfield: Chris Whitfield, Twitter. Additional comment to the last question. Often what I have found has happened, it’s not so much that there’s hardware that simply doesn’t support v6, but there’s a lot of hardware – I’m not going to name names – that where the software support for a particular model has been end of lifed, but with critical bugs unresolved that makes v6 impracticable to use on that hardware, at least in my environment. I’ve run into that a couple of times.

Dan Alexander: I think the other side of that question was very important, as far as when providers, when network operators are acquiring gear, it’s very important to get in front of the people that are making those purchasing decisions.

That was a considerable challenge for us when getting the v6 requirement into those purchasing decisions so gear wasn’t come onto the network that was then – you’ve committed yourself to a whole lifecycle where you now have to wait three, five-plus years before you can get that gear back out of the network.

I think a big piece of that was actually getting in front of the procurement people.

Louie Lee: Louie Lee, Google Fiber. So for each of you, when do you consider IPv4 to be no longer relevant to you? Or maybe to the rest of the net?

Right now the Alexa Top 1000 websites list says 18 percent are v6-reachable. I don’t know how to categorize it as the top 1,000 websites.

And your enterprise might not care about the top 1,000 if they can’t reach, say, PeopleSoft, their HR or Salesforce.

How do you deal with that? With Comcast, I think there’s some v6-only customers already. So maybe it’s not relevant to you anymore for v4. What are your thoughts on that?

Not just Comcast, but the others, too.

Dan Alexander: I can’t really speak to the long-range service or business plans.

Speaking personally, I have been saying for several years I always thought that tipping point was actually going to be reached the end of last year. So I was definitely off there when I was saying it five years ago. So I was a little off in my projections.

But I see that tipping point of where most general Internet users could get to the sites that they want to natively over v6 only. I see that coming a lot sooner than some people may feel.

I would like to see it happen this year. But I can’t really project that.

Rob Seastrom: It depends a lot on the class of customer. I’ll use my little sister as an example. She’s a paralegal. So the amount of stuff that she does on the Internet is constrained a little bit compared to what we would do.

I think with one exception – of course, I’m not going to name names in keeping with our tradition here, but if you look at the Alexa top 10 or 15, you can sort of figure that she would be pretty happy and might not notice if IPv6 was the only protocol and IPv4 went away completely with the exception of maybe one or two sites.

So the tipping point is incredibly close for a certain class of user. That’s not going to get us over the hump where we don’t have to have it out there at all, because, of course, like when we talk about cable modem management, the magic time we can get rid of IPv4 scopes on the CMTS is not when we get most of the cable modems over on to v6 management, it’s when we get the last cable modem over on to v6 management.

Owen DeLong: So I think there’s multiple levels of IPv4 no longer relevant. I think the first group where IPv4 is going to become no longer sufficiently relevant that they’ll want to pay what’s it’s going to cost will be the residential end-user.

I think that’s going to happen probably in the next four to nine years. Last year I was saying five to 10. I think we’re still on track for that. I don’t think it’s going to happen because they’re just no longer going to care about v4 as much as the providers that provide their service recognize the ever-increasing cost of maintaining carrier-grade NAT gateways and maintaining various hacks to allow them to provide some sort of v4 service to these people, they’re going to have to start charging a premium for that service.

And I think at the point that v4 costs more, more and more people are going to be willing to give up, the fewer and fewer sites that don’t support it.

So I think that’s where that tipping point is going to start; and then, of course, once a high enough percentage of the customers are no longer using v4 anyway because they don’t want to pay extra for it, then the content providers will start to say, well, why are we maintaining this? Nobody cares about it.

I think overall end-to-end that process may take about 15 to 20 years, but I think within the next four to nine years we will see the point where residential users start abandoning v4 at a relatively high rate of speed as it starts to cost more.

Charles Gucker: And I agree with Owen that the price of the public Internet connectivity will drive adoption of v6 over v4; but internally, privately within an enterprise, you have a much longer runway because they have to move all their services off and they’re historically, I’m going to make a very big generalization, enterprise customers don’t like the change for the sake of change. They’ll stay with what works until it breaks. So until it breaks, they’re not going to look at changing.

Andrew Dul: I’ll concur with that at the very end; that small and very large enterprises, I think, are very slow in adopting v6 and may still not even be on their radar in trying to get exposure to that.

It’s just something that the network works fine now, why do I want to do something new and different and manage – I’m going to have to manage two sets of firewall rules instead of one. They’re not there for sure.

And I don’t see them getting there anytime soon, until I think everybody realizes that their phone does v6-only and it talks to everything v6-only, then I think people will wake up and go, oh, maybe I do need to jump on this bandwagon and move my organization forward.

Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. So at sort of the high view, 30,000-foot view, I’ve got two sound bite views of what I’m hearing.

One is there’s a business advantage for our organization to deploy IPv6. Whether or not customers see the need today, we see the need; therefore, we’re deploying v6.

And then on the flip side what I hear is we are a large organization to be able to scale our organization moving forward, v6 makes sense for the size of our organization.

What I’m not hearing is because of the next great thing, our customers are demanding IPv6. And I guess five years ago we were all waiting for that app, the killer app that was going to use IPv6.

IoT has sort of been talked about this year as being that next big thing. But other than the slow progression of deployment for scalability or for business objectives, do any of you see a push from consumers or from the public for IPv6 in the next 24 to 36 months?

Andrew Dul: I think I’ll answer that no. I don’t see the killer app on the horizon right now. I think there’s possibility it still could come around. But I don’t see it right now.

Dan Alexander: I don’t necessarily think a killer app is coming, but I do feel that this tipping point will be reached where enough networks are v6-enabled where whoever is not will start playing a game of catch-up where they’ll have to catch up if they want to keep up kind of scenario.

Rob Seastrom: I believe there are customers who are principally interested in cat videos and social networking and they want it fast and they want it cheap.

So they want IPv6, they just don’t know they want IPv6, because they don’t care what protocol it’s delivered over so long as it’s good, fast and cheap. And, yes, they do want all three.

Owen DeLong: There are still people that drive Model-Ts. Not very many of them. But there are some out there.

So it will be with v4 in the future: There will still be some people clinging with their broken fingernails to the last vestiges of the v4 Internet for a very long time.

But just as you periodically replace your car because it starts to get too expensive to maintain the old one, people are going to slowly be developing ways to put v6 in their network instead of v4 because it’s getting more and more expensive to keep v4 running.

The large providers in the large organizations are feeling that pain earlier than the small consumers of v4, but there comes a point where, as more and more stuff is available on v6 and less and less consumers are able to support v4, or are less and less willing to pay for the added cost of staying on v4, v6 will become more and more dominant. That’s the closest thing we have to a killer application is the continued existence of an Internet that everybody fits on.

They don’t all fit today. Roughly one-third of the world’s population still isn’t on the Internet yet. And there’s no place to add them in the v4 space. So we’ll have to do something different.

And over the next few years I think that it’s pretty clear there aren’t enough different things we can do to juggle v4 and try to keep all the balls in the air and it just gets too expensive to do that.

So I think that’s as close as we come to a killer app. But, on the other hand, there are lots of car companies still selling new cars. So maybe that model works over time.

Chris Gucker: I echo a lot of what the panel said. Absent of these communities and internationally, most of the general Internet users don’t care v4 or v6, all they care is: Does this page load, send my email, anything past that they could not care less.

Kevin Blumberg: Thank you.

Aaron Hughes: Perhaps along those lines we can talk about successes a little bit. I certainly heard management is easier, scale is easier, location resolvers, geo information, the long addressing gives you unique identifiers to play with.

Have there been any other kinds of significant gains because of deploying v6? An example might be deployment of set top boxes or anything you’ve seen that’s interesting from your own respective organizations that v6 has made easier.

Chris Gucker: For one, for a backbone, it let me do a greenfield deployment and not deal with a lot of cruft that preexisted.

Dan Alexander: One thing I noticed is just simple operational ease in a sense: While a v6 address is much harder to recognize or to remember versus a v4 address, the fact that a lot of, whether it’s security or routing or different groups, when we’re micromanaging a v4 address and you have an ACL that’s 50 lines long versus you plop one prefix in that v6 filter and it quickly becomes a lot more recognizable and the v4 recognizability becomes irrelevant.

Rob Seastrom: Most people who haven’t worked at a really big company are unaware of just how quite easy it is to run out of NET 10.

And when you run out of NET 10, you start doing really bad things, like regionalizing your network and breaking the end-to-end principle. I see Vint nodding down there.

And it becomes very painful to do that. And we’re actually collapsing back some management functionality to things, because you don’t have to go through the scary proxy that you skip a request to query a cable modem through the thing that lives within the region where it talks – it all just sort of works.

Owen DeLong: Rather than express this in terms of additional benefits to v6, I’m going to kind of flip it around.

Day to day I spend my day working on a lot of things that are dual stacked. I spend the majority of my time dealing with problems that are unique to v4.

V6 just keeps working. It doesn’t run out of addresses. It doesn’t run into scaling problems. It doesn’t require me to re-address an exchange point because they went from a 24 to a 22 because they ran out of numbers for new members of the exchange, or renumbering the small island exchange point from a 28 to a 24, or any of those sorts of things that are all common occurrences in my day. v6 doesn’t have any of those problems.

On the few occasions when I’m working on a v6 problem, it’s actually something interesting, something unique, something new. Whereas, with v4 there’s just this day-to-day drudgery of scaling problems.

And the song is still the same thing. It’s the same thing over that v4 doesn’t scale and how did we fail to scale it today.

So there are so many drawbacks to v4 that tend to get ignored because we just take them for granted. But those drawbacks aren’t there in v6. And getting away from those drawbacks is worthwhile.

Chris Gucker: One operational thing I noticed is that when technicians go out and service equipment, they want to get into the management IP. When you’re in a v6-only environment they have to rely on DNS.

They can’t just remember 192.168, and blurt out the IT, that may or may not still be the device. From a scale perspective, if they’re forced to use DNS, it makes the consistency event much, much easier because now you know your management station’s given the same address as your technicians, as everyone else along the line, referring to the same thing and not believing what someone believed something once was.

Andrew Dul: I’d say the concept of subnet management goes away in v6. We’ve all spent probably lots of times operational time figuring out the right subnet or growing them or shrinking them, depending where they are.

That whole concept goes away when you just put 64s on all your interfaces. That’s just a workload we don’t have anymore. And thank goodness.

Aaron Hughes: We’ve got a couple of minutes left if you want to take any audience questions, more than happy to have a couple.

Jason Schiller: Jason Schiller, Google, ASO AC. Can you each talk about the reasons why you decided not to simply just keep buying IPv4 addresses or embrace carrier-grade NAT?

Andrew Dul: As a small organization, it didn’t really seem to be like the way to go, I would say. But I think it’s just that it’s inherently unscaleable if you look at the number of devices that exist today and where the trend line is going.

The number of silicon devices produced every year is some crazy number, in the billions, and all of those things need to be addressed. There’s no way we can scale with only four billion addresses.

Dan Alexander: For Comcast, the decision was a lot easier in the sense that it just wasn’t economical. I mean, when you look at how many devices we would like to provision, continuing to try and buy IP addresses and propagate that model and the amount of money that it would require, it’s actually cheaper to deploy v6.

Rob Seastrom: We had a similar experience at TWC. We have checked and evaluated CGN in the lab. We have it there as I guess you could call it a safety net but, boy, is it an expensive safety net.

I don’t think that any business plan that involves carrier-grade NAT is actually going to see the light of day and make it past the money people. It is simply too expensive.

Owen DeLong: CG NAT is a nonstarter for us because we’re on the content side of things and CG NAT doesn’t really do anything useful there.

In terms of buying IP addresses as a strategy versus going to v6, well, in our case that’s a false dichotomy. We’re probably going to end up buying IP addresses at some point in the near future.

We haven’t had to buy any yet. But we’re definitely scraping the bottom of the barrel in terms of what we can internally recycle and what we can get from providers.

Steve Ryan: Owen, Owen, stop. Do not give information about individual companies.

Aaron Hughes: I think that was a comment from legal to move the conversation along.

Owen DeLong: Let me wrap up without the specifics. The bottom line is we’re going to have to do both. And there’s other solutions available, too.

Charles Gucker: As a cloud services provider, we are the target for a lot of workloads. So a majority of our connectivity comes in through direct connects or private connectivity from the individual enterprise.

So egress and connectivity requirements are less. Although we still do buy v4 address space. It’s only because we have to meet the requirements of the customer on the other side and a majority of that IP space is used as IPsec or VXLAN target addresses.

So everything would be an overlay on top of it at the customer’s architecture.

Aaron Hughes: Thank you. Dani, do you have a question or are you just standing up?

Dani Roisman: I had a quick comment. There was a question earlier that was posed what do you – Dani Roisman with SoftLayer.

There was a question posed: What do you do with old equipment. I didn’t hear anybody mention it. I think word of caution, I don’t think it makes sense to take old IPv4-only equipment and ship it out to less developed areas. Because they’ll run into this problem in some number of years. And it’s going be even more painful for them.

I would encourage anybody who is in a less developed area not to seek out older equipment which is not v6-compatible and they really want to start moving with the most current capability so they can make sure they can stay connected to the rest of the modern Internet.

Aaron Hughes: Bill.

Bill Woodcock: Following up on that. As someone who ships equipment to developing countries regularly, the cost of shipping old equipment around the world far exceeds the value of the equipment.

People in the developing world typically want things that are small, fast and new because the shipping cost makes much more difference than the difference between old and new equipment cost.

Aaron Hughes: Great point. Okay. So we’ve got just a couple of minutes left. So you each can give any last comments you have and we’ll close this up.

Andrew Dul: I think for those who haven’t started on the v6 road, it’s time to start.

And I think people in various aspects just have not been able to get their mind around the fact that the network underlying is changing and it’s really hard when you don’t see that for so many years.

My mom and dad understand what I do here but don’t necessarily know the details underneath that. And having to explain it to them and having them work through it is kind of interesting, but at the same time that has to happen in every organization.

And the level, the knowledge level between v4 and v6 is still significant, but the gap is closing. And I think that is very significant and definitely very positive for the future, I think, of the v6 network.

Dan Alexander: I would probably echo that and just continue with: There’s been a bit of complacency that’s developed over the years as we’ve had these conversations and this transition has stretched on as long as it has. And we’ve been dealing with IPv4 depletion.

And it’s a little risky in the sense that a lot of people have gotten some bad information thinking, oh, this may be another 10 years before we have to do anything or we don’t have to worry about it right now. And I think for a lot of people this transition is going to sneak up on them a lot faster than they expected, given the rate of change that’s going on in the Internet right now, v6 is going to come on pretty quickly and hopefully it doesn’t catch too many people off guard.

Rob Seastrom: There have been two recurring themes in my conversations with people, both inside my day job and outside with a lot of people come to me say you’re on the ARIN Advisory Council, can you give me some advice on this v6 thing.

The first is there’s a difference between conservation and just not wasting.

And the conservation mandate for v4 is dead when you’re talking about v6. We want to optimize for brain cells, not for address utilization.

Any kind of variable according to need subnetting plan or anything like that is simply wasted time, it’s a bad idea and you’ll regret it later once you understand how it all works.

So the notion of trying to save space is simply a poor one. And this dovetails with the advice that I’ve given to folks who are coming to ARIN, which to get an additional or an initial allocation of space, which is how big is your service provider really?

That /32 is the default allocation. It is not the only allocation. You almost certainly can justify more space than a /32 if you’re not a trivially small-sized organization. What’s the worst they can do? They can say no. Draw up your hopes and dreams and ask for it. You’ll probably get it.

And that’s been just such a hard thing for folks to wrap their heads around.

Owen DeLong: Yeah, I’m going to echo what Rob said. I used to work for an Internet service provider, not a residential provider but a backbone provider. And during my time there they managed to pretty well run out of their /32 and we went back to ARIN and got a 24.

So it’s not hard to get the space you need in v6. It’s very, very easy. We’ve modified the policy several years back such that you can do some quick back-of-the-envelope calculations relatively quickly and easily and come up with a subnet size or a prefix size that is fairly generous in nature and hand that to ARIN and say we want this.

And if you give them a copy of your back-of-the-envelope calculations, they look at it you’ll probably get it. It’s really simple.

That will save you a lot of headaches going forward if you get the right size block instead of trying to figure out how to compress everything into a /32. It’s just not a good idea.

Chris Gucker: Unlike a lot of the other panelists, I’ve been in an environment dealing predominantly with enterprise and no residential users.

So I kind of faced a lot of the problems that the service providers faced 10 years ago with getting vendor support. Although, it’s internally within the company, where I need customer demand to help solidify the entire stack, because from an engineering perspective we’re able to tackle one application or one abstraction layer but not all of them without a complete solution.

So if you do know any enterprise customers that want to help push for a complete stack for solutions all the way through with v6, that would definitely help, because it’s kind of a Catch-22, like we were a number of years ago, when I was on the residential side.

So just bringing it full circle is the residential seems to be really pushing forward. The enterprise are very happy staying where they are until things start breaking. And they’re happy to claim that nothing’s broken because they still can’t do certain aspects of v6.

Aaron Hughes: Certainly understandable that enterprise demand is going to trail the network side.

But I really liked hearing all of these experiences. And I want to thank everybody for their knowledge, their time in sharing their experiences here at this meeting.

Thanks very much, guys.

(Applause.)

John Curran: Thank you for that wonderful panel. We’re now going to move into lunch. Lunch is across the way. So out the doors, down the steps, back where registration is.

We’re going to be at lunch until 1:30. There is AC table topics. So you can find the Advisory Council members at tables that have signs on them. If you’re interested in a topic, sit at that particular table. So there’s a topic on how to join the AC, if you want to run for the ARIN Advisory Council.

There’s a table on discussing need. We use operational need in determining whether somebody can be assigned, allocated or have a transfer done. IPv6 for small organizations and a table topic on useful policy changes as a result of the new fee schedule.

When you go across for lunch, if you have a particular topic you want to talk about, you can find an AC member who are interested in those topics across the way.

Take your valuables with you. The room is not locked and is wide open. If you have something real valuable a small bag of IPv4 addresses, just carry it out and across the way.

Remember we come back at 1:30. Please come back promptly. Thank you.

Remarks from Network Sponsor

John Curran: If folks will come in and be seated. We have a busy agenda. We’ve got two draft policies coming up that we need to consider – Draft Policy and Recommended Draft Policy, Draft Policy 2015-2, Inter-RIR Transfers to Specified Recipients, and Recommended Draft Policy 2015-3, and moving the 30-day utilization requirement in end-user IPv4.

We have an Importance of Whois Accuracy update. We have the Software Development Update. Before those two, we’re going to get the IETF Report that we missed this morning.

So a lot of stuff to get done. I’ll get started now. At the head table we have Vint Cerf, our chairman; Paul Andersen, vice chair; Dan Alexander; Blumberg, Kevin; and Andrew Dul, our scribe.

I blank on faces for some reason.

I want to start out by spending a little time thanking our sponsor for this meeting, and so I’m going to ask Donovan White to come up. He’s the Vice President of C&W Business. He’s got 18 years of experience in telecommunications, media, and cable; held several senior positions at Digicel. Now works as vice president at C&W Business. He has a BA in marketing from the University of New Orleans and an executive MBA from the Telecoms Academy.

I’d like to invite up our sponsor, Donovan White.

(Applause.)

Donovan White: Thank you. How are we doing? How was lunch? I won’t be long. Just let me get through the salutations. John Curran, president and CEO of ARIN, and Vint Cerf, chairman, and other members of the head table and Board of Trustees and members of the Advisory Council, members of the NRO Number Council, RIR members, and distinguished ladies and gentlemen, good evening. It’s my pleasure and privilege to welcome you to our most beautiful island or the most beautiful island in the Caribbean, Jamaica.

(Applause.)

You’ll hear some of us say it’s the land of wood and water, and also we believe it is one of the best places in the world to live, work, raise families and do business.

More specifically, though, I want to extend a warm welcome to our second city, Montego Bay, which is the hub of our tourism products, one of our key tourism drivers. Together with tourism, Montego Bay also holds the fastest growing business sector of the island through the growth of the BPOs.

For us at C&W Business, it’s very gratifying that you have chosen Jamaica, ARIN chose Jamaica. C&W Business is a subsidiary of C&W Communications, and we are your trusted sponsors at ARIN 37.

It’s an opportunity we were only too happy to grab with both hands when it was offered. We will bring to bear in this year’s conference the most advanced technology from the region as well as more than 140 years of experience.

Today, Cable & Wireless own and manage the sub C fiber network that connects and powers the Caribbean and the Latin America region through a state-of-the-art network that spans more than 42,000 kilometers of fiber, by far the most extensive across the region. And terrestrially we have deployed more than 30,000 kilometers of fiber, delivering wholesale and carry a backhaul capacity to governments, ISVs and large and small Internet enterprises.

We are indeed proud of our achievements through our ability to deliver a wide range of solutions which range from simple telephony and Internet to the more complex local and international MPLS services and a wide range of managed services from our five Tier 3 datacenters and one Tier 4 datacenter across the region.

In today’s changing world and especially in the technology space, it is important that businesses choose the right partners that can deliver the best and most cognitive solutions to place or keep them in an advanced state of the technology evolution. We continue to do that with tens of thousands of partners across Jamaica and the wider region while continuing to invest heavily in our core infrastructure.

As the network partners of ARIN 37 conference, C&W Business is providing high-speed connectivity as well as supporting the technology infrastructure to ensure all the delegates and attendees are properly connected and stay connected throughout the duration of this conference.

In closing – or before I close, I have one observation that I mentioned to our president a minute ago, I would have loved to have seen, as part of the panel discussion, more persons from the region, ISPs and engineers and large enterprises who use the services having an input into the discussion. And so I’m hoping, and I see him nodding, so I know that he’s making it known, that for the next conference we’ll see more of the Caribbean and Latin America represented as part of the policy-making discussions.

In closing, do enjoy the balance of the conference. Please feel free to engage us today and until the conference ends. We have some of our best engineers in this room amongst you. So do pick their brains, and I’m sure they’ll be picking yours. Most of all, please enjoy the hospitality of my fellow Jamaicans. Thank you for being here.

(Applause.)

John Curran: Excellent. What a wonderful host. We’re going to get started now on the policy discussions. It should be an interesting time. The first policy up is Draft Policy 2015-2. We’ll have Chris Tacit come up from the AC to give a presentation.

Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients)

Chris Tacit: The problem statement was articulated about a year ago now and basically had to do with the fact that organizations that obtain a needs-based supply of IP addresses via the transfer market may have an unexpected change in their business plan and may need to use those addresses in another region.

Now the problem isn’t caused so much by ARIN per se because ARIN policy doesn’t restrict the use of ARIN source IP addresses globally, but there are other registries that require a movement of numbering resources to their regions, specifically countries within their regions, in order to legitimately be able to use those IP addresses in their region.

This is the current text of the fourth bullet of Section 8.4 of the NRPM, and it is the bullet, the only bullet within that section that would be affected by this proposed policy.

The initial proposal was simply to remove the word “transfer” so there would no longer be any constraints on the movement of resources within the first 12 months in the case of a transfer.

However – so it would facilitate this use that, that I just discussed, so that the resources wouldn’t be locked in the ARIN Whois for 12 months.

So under the current policy, as I said, an organization is prohibited from moving some or all of those addresses to another region’s Whois if there is a need to remove them, and that need doesn’t relate to ARIN policy but the other RIRs’ policies, or national policies in some cases.

So because other types of transfers coming in to what is an entity that may be global in scope is approved on a 24-month supply, there’s often a situation where the business needs of the organization can change in the first year.

So there’s a lot of discussion about removing that word “transfer” from that bullet early on on PPML. One view was that this isn’t ARIN’s problem. Resources can be requested from another region instead. The other view was that ARIN members operating global networks prefer to deal with one RIR as much as possible, and this policy would reduce incentives to use other means to essentially bypass the anti-flip provision, as it’s called, that constitutes that fourth bullet of Section 8.4.

So initially what we tried to do is to propose a requirement of some sort of corporate affiliation between the source and the recipient entities to make it more likely that eliminating the 12-month anti-flip period in that situation will meet the needs of the multi-region network operators without encouraging abuse.

Following input received at the NANOG 66 PPC and on PPML, the proposed – the fourth bullet of Section 8.4 was changed in the manner that was being considered. And that modification would have added two new definitions to the NRPM. Those would be “affiliated” and “control.” I don’t want to dwell on this because in the end we didn’t go this way as the shepherds of the policy.

A staff and legal analysis was received regarding the proposal that indicated that it could be implemented as written but there were some qualifications. First of all, the definition of control wouldn’t be applied to Section 8.2 transfer cases because that would conflict with staff responsibility to ensure fully researched and vetted chains of authority for M&A situations.

And general counsel expressed concerns with the proposed definitions of “affiliated” and “control.” Although they were based on statutory provisions, the reality is that if you get into that level of definition, whatever you choose has to work across multiple jurisdictions that constitute the ARIN region.

So for that reason caution was urged, essentially, and an alternative formulations of these definitions were proposed.

General counsel also reminded us that the reason for this problem isn’t ARIN’s policy per se but the requirements of other RIRs, as I said at the beginning. So we did amend the problem statement to point that out.

So following these developments, we thought about what to do and instead of trying to continue tinkering with those definitions and also based on the recollection of one comment received at NANOG from one participant that said they would have wanted a simpler formulation for this, we decided to test out dumping the definitions altogether and just using words that certainly have legal meaning but don’t require a lot of extra explanation within the NRPM itself.

So you’ll see that the red text there is the latest text that’s been introduced into this bullet. So basically there is an affiliation agreement that is still maintained. And this reflects the community views that were expressed generally that this is a good way to proceed but without the extra complication of definitions.

And we made that other clarification that we discussed that the requirement for this results from other RIR constraints.

Paul Andersen: Are you raising a point in the middle? There’s a question that seems to be pressing.

Jason Schiller: Jason Schiller, Google, ASO AC. I just want to clarify what you just said to make sure it’s clear to everybody in the room. As printed in the Discussion Guide, the Draft Policy 2015-2 says it includes adding a new section, 2.17, as the definition of affiliated and 2.18 as the definition of control. Those are no longer officially part of the proposed text.

Chris Tacit: No, no –

Jason Schiller: So the Discussion Guide as printed is incorrect?

Chris Tacit: That’s right. This change was much more recent. Thank you for pointing it out. It was a much more recent change. It came after the printing deadline.

There hasn’t been much feedback on PPML other than a question directed at staff regarding how often the situation is encountered, and staff had committed to investigate and report back. I don’t know if we have that answer yet or not. But that’s something maybe you can talk about later.

And just this morning, hot off the press, we received the revised staff and legal analysis. The staff analysis is very clean. It basically says the proposal can be implemented as drafted.

General counsel indicated that prior concerns have been satisfied and implementation could go ahead if this is implemented with minimal resource impact and would occur three months after ratification by the ARIN Board.

So the questions we as the shepherds have for you this afternoon are, one, does this revised text, the latest text that you just saw, strike the appropriate balance between the needs of global multi-network operators and fraud mitigation? Is the proposed text sufficiently clear? And do you have anything other concerns?

And before engaging in that discussion, I wanted to thank Cathy Aronson, who is actually the primary shepherd on this, for giving me some room to maneuver. I wanted to try my hand at going ahead with this one just to get some more practice in since I’m a relatively new AC member.

But I did rely on her counsel heavily in the process. I wanted to give her recognition for that and also for the quick turnaround by staff on the second, that staff and legal analysis.

Paul Andersen: I’ll open the microphones. Before we go to the microphones, I thought it would be useful to take a second, since it’s the first policy, to state it’s important that anybody who has a comment who would like to speak about the proposal, the merits or not, you should approach a mic. We also have the remote participation. They’ll be able to participate.

It’s very important that if you have something, even if it’s just to say I support this proposal because it would help my business or I have a problem because it will hurt, or just either I support or not, it’s extremely valuable input to the AC because they, after this – what will happen after this meeting, they will meet on Wednesday and they will have to make a decision on what to do with this policy.

So I just thought it would be useful to take a quick second to remind that. With that, I’d love to have people approach the microphones, and we’ll start with the front microphone. And, of course, remind you to say your name and affiliation, if any, before speaking.

Cathy Aronson: I’m Cathy Aronson. Since it’s not in the Discussion Guide, can we put it back to the meaty bit of the text so people have a chance to look at it while they’re raising their issues or whatever? Thanks.

Paul Andersen: Vint has a point. Go ahead.

Vint Cerf: This is a question for counsel. Is counsel in the room? I see him trying to escape now.

Specifically the red-colored text reads: Unless either the source and recipient entities own or control each other.

I have questions about how to interpret that, because legal structures usually don’t involve companies owning each other. There’s usually one or the other controls the other one. So I’m not sure that this language makes sense. So, counsel, can you respond, please.

Paul Andersen: Counsel, rear microphone.

Steve Ryan: Vint, I didn’t draft the language, but I think there’s two different intents in the language. One is for the wholly-owned subsidiary where a holding company owns long strings of subsidiaries. And then the control issue would be where you don’t own it outright but you have control through the shares or some other mechanism of control that allows you to control the entity.

So it’s the combination of the two words in a single sentence that may be the root of your concern. As we interpret this language, and I want everybody to actually pay attention to the lawyer for about 60 seconds, we’re going to actually interpret this that if spammer one is trying to convey the assets to spammer two because spammer one has court orders against them or is somehow in trouble, we’re going to look very carefully at those kind of control activities.

We’re also going to someday be in a 2 percent case where we will tell a company that they haven’t successfully proven ownership or control despite what they may believe is adequate proof of ownership or control. It will be a legal judgment based in part on the business ownership that we see in the records in the world and in the technology that’s employed.

So if that helps people understand, there is a substantial legal judgment that ARIN’s actually quite skilled at and normally doesn’t require the general counsel to do. The businesspeople at ARIN know how to look at chains of corporation and evaluate this.

But there will be times where it gets kicked out of that loop and it will be looked at at a higher level. And ultimately Mr. Curran represents an appeal mechanism if somebody believes that the staff and the lawyers have come up with an erroneous decision.

Paul Andersen: Did that address your question?

Vint Cerf: No. It partly addresses it. But I would suggest for consideration that this language be revised. I know that’s a big pain in the neck. But what is really intended, according to my understanding, is the following: Unless either the source or recipient entity owns or controls the other, because this notion of owning and controlling each other literally does not make any sense. It’s only something that would happen between consenting companies in California as far as I can tell.

(Laughter.)

Vint Cerf: So I would recommend clarity here is in our favor. I would leave it at that for your consideration.

Steve Ryan: Sir, Mr. Tacit is a lawyer, and he’s been very helpful in this process. There was another formulation, Christopher, where you and I went over this exact issue, and maybe we should look back at what we had and see if it in some way addresses Vint’s concern.

Paul Andersen: I think Chris wanted to address some concern here.

Chris Tacit: That’s fine. We’ll look at it and see if this isn’t clear enough. I think that was a good suggestion for general counsel and I to work together on this to see if it does make sense or needs further clarification.

But the overall intent, we just want to be clear, whether we use this or some slightly different nuanced language, the intent is to make it a fairly simple and straightforward legal test that is one with which, as general counsel said, there is experience in application and, moreover, which is certainly known in law.

People know in law what ownership and control mean, and certainly even inside counsel at ARIN would be well versed in that to assist in advising staff as necessary.

So we’re trying to keep it simple and have this as a backstop to the concern about bypassing the anti-flip in inappropriate ways.

John Curran: In looking at this very carefully at the first clause and the language, “own or control each other,” that establishes a set of conditions that – I understand exactly what you mean by this, and I think the policy makes sense with what you mean – but in the exact literal interpretation, you probably can’t have two entities owning and controlling each other at the same time. So there’s some language parsing that needs to be fixed. But that doesn’t change the intent. I think that’s fine.

Vint Cerf: That’s what I said, John.

John Curran: Right. I’m just taking a long time to agree with you.

John Springer: John Springer, ARIN AC. My question had to do with the link in the agenda online, links to text dated the 11th of April. Is this text today, the 18th of April, identical to the 11th?

Chris Tacit: It should be, unless there’s a typo somewhere.

Paul Andersen: Kevin Blumberg was –

Kevin Blumberg: Thank you. Kevin Blumberg, The Wire, ARIN AC. I’m seeing one use case given here, and we have a lot of people from the community I think that I’d like to hear from in terms of the other uses for this policy.

The first thing that comes to mind is, at least I’ve seen in the news, a number of organizations who over the last 12 months have set up situations in Germany and Ireland, et cetera, for keeping their data isolated from North America.

And to me this seems like a perfect example where an organization in North America who has just gotten a large block of space from the ARIN region might want to hive off some of that space and for legal reasons feels that it is in their best interests to keep it in a different RIR.

So that’s one use case I sort of can, on the back of my paper, write down, and my question is: Are there other use cases that the community sees? How targeted is this policy? Because it seems to me it’s actually more broad than the way it’s being described.

Paul Andersen: Kevin, would you be in support?

Kevin Blumberg: I’d like to hear more from the community. I think I’m in support if it’s a broader policy. But I’m concerned about how scalpel focused this policy seems right now. But I don’t believe that’s actually the case.

Paul Andersen: We’ve got about five more minutes of discussion. If you would like to speak on this topic, I’d encourage you to approach a microphone. And we’ll go with the front first.

Owen DeLong: Owen DeLong, Akamai, ARIN AC, and member of the community. Even the proposers of this policy have at this point stated that it’s pretty much a corner case and fairly narrowly focused. I believe that to be the continuing case, though, it would address the broader issue that Kevin has raised. I don’t know that anybody is clamoring for that broader issue to be addressed as yet. I haven’t heard such a thing until Kevin proposed it.

I’m opposed to the policy at this current point. I believe Vint’s issue can be easily addressed by changing “each” to “the” and moving on, a quick editorial change that doesn’t change the intent of the policy. So that can be cleaned up before it goes to last call if we decide to move it forward.

But I remain opposed to the policy because I think the can of worms that opens in terms of bypassing the anti-flip provisions is much, much larger than the problem it is trying to solve.

Paul Andersen: Rear microphone.

Milton Mueller: Milton Mueller, Georgia Institute of Technology and AC member. I was just going to propose a very simple language modification that would solve Vint’s problem. So it should read: Unless either the source or recipient entity is owned or controlled by the other, comma, or both are under common ownership or control. So that seems that it solves that problem.

And in terms of the intent of the policy, I think I support it. I think it’s dealing with, again, maybe a small number of cases, but it does solve a problem that might happen fairly frequently in the future. And I don’t see the loophole problem because I don’t see a big reason for somebody to go through all of this rigmarole to simply flip a /24 or something. So that’s my view.

Paul Andersen: Anybody else that would like to speak or make a comment on this proposal? Andrew? – Andrew is doing jabber, right?

We’ll be closing the microphones in a few seconds, if I don’t see people making approach. Going once, twice? Three times. Microphones are closed. Let’s thank Chris for the presentation.

(Applause.)

Paul Andersen: So we’re going to a poll. I’ll speak slowly for a second as the counters get into position and give me the green light.

The question that we’re going to be asking is whether you believe the Advisory Council should continue to work on this proposal. Correct, Dan? That’s what you’d like at this time? So I’d like to ask you to raise your hand if you’re in support, and I’ll ask those to raise their hand if they are against. Keep your hand raised until I ask you to lower. It’s a great little exercise after lunch. And we also need a bit of time for the remote participation. So, looking for the thumbs up. Thumps up.

Those in favor of the Advisory Council continuing to work on this, please raise your hand nice and high. One hand only, please. Please keep it up. Those, of course, online, please follow the instructions to show your support or not.

You may lower your hands now. And if you – now I would ask those that are opposed to the Advisory Council continuing to work on this proposal to raise their hand nice and high.

Thank you. You may lower. Give us one second to do the tabulations.

John Curran: As a reminder, everyone is entitled to participate in the policy process including the show of support. So if you’re sitting there wondering, did I need a special card or stamp? Does my badge need to say something? No, you’re entitled to participate.

A number of us curtail our participation. That should not surprise you. You won’t see me raising or lowering my hand. Some of the other RIR staff tend not to.

The Advisory Council and Board, it’s at their discretion. Certainly we have people who go both ways. ARIN staff generally refrain as well.

But you are free to participate. No special accreditation is required. It’s open to everyone.

Paul Andersen: Thank you very much. And the envelope. On the matter of 2015-2, modify 8.4, we had 105 in the room, three remote. That’s a total of 108. 29 are in favor; one against.

This feedback is being provided to the Advisory Council for their consideration. Thank you. Turn it over to John.

John Curran: Thank you. Okay, thank you very much, Chris and Paul, for handling that. We’re now going to move on to Recommended Draft Policy 2015-3: Removing the 30-day utilization requirement in end-user IPv4 policy.

Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy

John Curran: I’ll do the introduction of this. This is a Recommended Draft Policy. Something important to know. This policy, if recommended by you, and if then well considered by the AC as a result, could go to the Board of Trustees after this meeting to be adopted.

So this policy is a potential change. It’s reached a stage of advancement in the policy process that we may be making a change if it’s favorably considered. Hence, we’re somewhat rigorous in how we do this part.

I, therefore, will do the policy introduction. This was introduced as ARIN Policy Proposal 217 in May 2015. The AC shepherds, the two members of the AC responsible for guiding it through the process, David Farmer and Leif Sawyer. It was presented at ARIN Public Policy Consultation at NANOG 64 in June of 2015. And it was presented at the ARIN 36 meeting in October 2015.

It was advanced by the AC to Recommended Draft Policy state in March of 2016, which meant the AC felt it met the criteria for suitable change to ARIN policy. The text is online and in the Discussion Guide.

Staff understanding: This proposal would remove the 25 percent utilization requirement, which is a requirement that says you have to use 25 percent of the address block that we issued to you within 30 days of its issuance as a criteria bullet point currently in the NRPM, the Number Resource Policy Manual, in Section 4.3.3.

Your Discussion Guide has a copy of the full Number Resource Policy Manual. So you can go look at NRPM Section 4.3.3 and see where we’re removing that.

Staff comments: The policy would closely align with the way staff applies the existing policy to 8.3 transfers. Because there’s no longer an IPv4 free pool and many IPv4 requests are likely to be satisfied by 8.3 transfers, the adoption of this policy should have no major impact on operations and could be implemented as written.

There’s no material legal risk in the policy. It’s the legal assessment from counsel.

The resource impact: If adopted, this policy would have minimal resource impact from an implementation aspect. It’s estimated that it could occur shortly after ratification by the Board of Trustees. We would need to update internal guidelines and internal procedures and update our staff training materials.

So I’ll now turn it over to David Farmer of the ARIN Advisory Council who will give the Advisory Council report on this policy.

David Farmer: Same information. We’re still talking about removing the 30-day utilization requirement for end users. And this is the problem statement for the policy. The requirements – we’re handing out a year’s worth of address space, basically, and, as was said, there’s currently a 25 percent requirement of immediate utilization – immediate is being interpreted as 30 days by staff – this removes an unrealistic expectation, et cetera.

So this is the current text, and basically we’re going to zap that line. Well, when we do this, we need to do some additional editorial things here because what’s left kind of doesn’t make sense all by itself. So we do some minor editorial changes here and turn – take the last sentence fragment in this and bind it all together and make a new paragraph.

And so it often takes longer than 30 days to stage and start equipment and actually use the addresses. If you’re starting from zero, it’s kind of hard to do sometimes. That growth is not regimented in this way. It happens in spurts. This doesn’t really account for that.

It also applies to additional requests or transfers of new space, and in that case you’re supposed to be 80 percent utilized, and so there’s some disconnect here in the way these work.

And as was noted – so another change that’s happening is with runout, part of this was also with the slow start policy and various other things where an end-user – the intent was the end-user would get space from their ISP, get started, then, once they get to a certain size, then they come to ARIN.

Well, there’s no ARIN free pool. ISPs can’t get space very easily. Users are – the whole system doesn’t work any longer. So these requirements are onerous now in current conditions. So there’s been a good amount of discussion of this on PPML. As was noted, it was presented at the PPC and NANOG 36 in Montreal. There’s agreement there’s a definite issue here. There’s strong support. There’s a small amount of opposition in this, and I’ll explain that right here.

So the opposition seems to be that this removes the only tangible and verifiable claim. Basically all that’s left is this forward-looking projection for a year.

The commenter would like there to be some sort of tangible and verifiable commitment to using half the address space within a year.

Staff assessment as was discussed, continued. So one of the things the staff assessment includes is a notation that RFC 2050 is referenced. And that’s no longer – that’s now a historic document. And a similar – there’s a similar policy artifact in 4.2.3.6. This was brought up in Montreal. And the feedback from Montreal was keep this policy narrowly focused on 4.3.3 and do other work to clean those other things up.

So that’s where we’re at right now. Question to you all for the discussion is: Is this ready for last call? How can we and should we address the opposition? And if we do something to address the opposition, should we clean up those other things?

Paul Andersen: Thank you. So we open the microphones, but if you’re new, since this is our first Recommended Draft Policy, there’s a very excellent flow chart I ask you to all look at, page 20 in the book. You’ll notice this policy is already at Step 7. So this is the last time this policy may – may be discussed at a meeting like this.

If you have a concern, now is an excellent time to raise it. If you’d like to give a push of support, that’s also very important. As opposed to the last policy, which is still kind of in that three, four and can loop-around a few times. This policy, if the poll question we’ll have at the end has strong support, could be the next step into moving on to last call.

Just a little for the people this might be their first time, and for those that have been around for a while. I tried to stretch that out, hoping there would be a queue of people at the microphones.

First we’ll go to the front microphone.

Alyssa Moore: Alyssa Moore with Cybera and also a Fellow. This is my first meeting. I noticed the opposition says that 25 percent clause is the only verifiable element of the policy. I’m just wondering how often or if at all these things are checked up upon and verified.

Paul Andersen: I’m going to ask John Curran – you don’t get to run away that easily. I know. John Curran to address.

John Curran: So it’s actually something we do check up on. Meaning that the requirement says you’ll use 25 percent within 30 days. We have been known to call organizations, particularly ones with particularly aggressive blocks, and ask them about their utilization information, because we are required to check up on such.

Note that now that people are transferring blocks, because we don’t have a free pool and they can transfer up to two years, the 25 percent utilization comes at a much higher threshold because the block is larger. So that’s a lot of work in 30 days.

It makes sense to allow a large block because, in two years worth, because going through a transfer is more work than just getting an assignment.

But the impact on the lower end is we have the potential of calling someone and saying, show us your 30-day utilization, and for someone who has gotten a large block within their allocation, it can be very difficult to show it got operationally used.

We do check. We’re more likely to find someone who has a problem now because they’re doing a transfer of a larger block than what we would have assigned out of the free pool. Did that help?

Paul Andersen: Does that answer your question? Now, with that data, would you support the policy?

Alyssa Moore: Yes.

Paul Andersen: Thank you. Kevin Blumberg, I believe was next. And I would encourage, of course, to use this time to approach the microphone because we do need some discussion.

Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. And it sort of actually ties directly into what John said. I’d really like to understand from staff how the 25 and 50 percent right now that’s in here applies when we’re now talking about transfers which are 24 months.

It’s a very different metric. So if you could sort of explain, because the 25 and 50 percent based on 30 in one year is based on free pool, where 8.2 – sorry, 8.3, 8.4 is 24-month.

Paul Andersen: Okay. Thank you. Other comments, maybe remote.

Again, it’s important even just to approach a microphone, say your name and either “I support” or “I do not support.” It’s good feedback to the room. Front microphone.

Owen DeLong: Owen DeLong, Akamai, ARIN AC, member of the community. I generally support the proposal. I’d like to see the oppositions issue get addressed if possible but not to the point of delaying this because I think it’s needed. So it probably won’t get addressed. But maybe we can do something about that in the future.

Definitely the RFC 2050 references in 4.2.3.6 is a separate issue, and let’s just clean that up later.

Paul Andersen: Thank you. Comment onstage?

Dan Alexander: I wanted to clarify. Kevin’s point wasn’t a point, it was a question. So I didn’t know if John wanted to actually respond to that.

Paul Andersen: Could you repeat the question, Kevin? I think a bunch of us missed it. Our apologies.

John Curran: I missed the question part of it.

Kevin Blumberg: The question was, to clarify for everybody, when it comes – this policy is in reference to free pool space. When you take into account that almost every request will now be based on transfer via 8.3 or 8.4, which has a 24-month, can you explain how staff calculates in transfers versus what – when somebody is just reading and saying 25 percent over 30 days, how does that now work with a 24-month transfer?

John Curran: It still requires them to use 25 percent of the block being transferred. Now, this is the unfortunate circumstance of having transfer policies which chained to needs assessment which come from allocation and assignment policies in elsewhere in the NRPM.

When the AC has some free time, if it would like to unwind those, that would be greatly appreciated.

Paul Andersen: Hint, hint. That was a subtle message John, thanks.

Other comments or questions? People still recovering from lunch, I think. Rear microphone.

Jason Schiller: Jason Schiller, Google, ASO AC. Can you go back to the oppositions slide.

And I should say I support the concept. I strongly support removing the 30-day need. I’m not sure I support it as written.

I wish people would stop referring to this as the opposition, because the person who wrote this is actually in support of this policy. However, the concern is the 30-day check is the only teeth that this policy has. And without any teeth at all, this could become an avenue for abuse. It could basically allow anyone to make any sort of two-year projection claim and transfer something and basically use it as an end run around needs-based justification. And that is really my concern with the policy as written.

Back in January I suggested some alternate language that basically that there should be some tangible and verifiable claim to show that they’re going to use 50 percent of the address space within one year.

I didn’t see a lot of objection to that on the Mailing List. So I’d like to ask the room here if people object to adding some sort of requirement for tangible and a verifiable claim of the plan to use the address space within one year.

I also gave three kind of approaches. It could either be very vague, it could be open ended with some examples of things that would be accepted, or we could have some specific list of criteria on. So I’d like to hear responses to that.

Paul Andersen: Jason, don’t run away quite yet.

David Farmer: I’ll agree there wasn’t a lot of objection. There wasn’t a lot of support either. It was a toss-up as the shepherd that I sort of took, and I apologize if that’s not what the community wants. But sometimes it’s hard to read the community.

The other thing, I apologize for the opposition. I just couldn’t find a better word that fits on slides and things like that. If you’ve got better words for that, let me know.

Jason Schiller: I think the important point here is I have concerns about abuse and I’d like to close that loophole. It’s not that I oppose the policy.

Paul Andersen: So you don’t oppose the policy as written?

Jason Schiller: I do not support the policy as written because I’m concerned that there are loopholes for abuse. I don’t want to see those become an end run around justified need for end users.

Chris Woodfield: Chris Woodfield, Twitter. I came up to ask a question that Jason just answered in his statement, which was had there been any consideration of extending the verification term as versus removing it entirely?

I would support a policy that – I would support a policy that extended that the deadline to show utilization. I would not support a policy that eliminated the need for that check entirely.

Paul Andersen: Thank you. Head table, Vint.

Vint Cerf: Vint Cerf, Google, and chairman of the Board. I thought in response to that last remark that there’s still an element in there saying 50 percent within a year. So is that not tested ever? That’s a question for John.

John Curran: We can go back on the present policy and confirm that someone has done the utilization that they claim they do, but it’s much more difficult to know whether or not someone has made a fraudulent request if we don’t check shortly after we’ve assigned to them.

In other words, someone will find address space utilization within a year one way or the other. But whether or not they’re valid for what we assigned is much easier to determine if they’ve made use of it within the first 30 days, or 30 days, 60 days, the immediate future.

A year from now companies go through major changes. So I’m not saying that it’s not something we can confirm. We can ask them, but it doesn’t validate whether their original request was the right size.

Paul Andersen: I was going to ask you does it answer your question, but you have a look of perplexity.

Vint Cerf: It’s a response to the question. We’ll put it that way.

Paul Andersen: Before we go to the front microphone, we’re going to be closing the microphones very shortly, so please come up quickly or start typing in remote participation, if you have a comment, but we’re going to be closing –

David Huberman: Why are we closing the microphones? Why are we giving five and ten, 15 minutes for these? We have things to talk about. Can we please talk about them?

Paul Andersen: If the microphone starts to line up, I am happy to keep talking. But at some point I need to encourage people to either come say something or we have to move on. But I have no problem if there is stuff to say.

Front microphone.

David Huberman: David Huberman from Oracle. Let’s talk about what Jason and Chris’s concept looks like. We’re not assigning IP addresses out of a free pool here. We’re talking about IPv4. We’re talking about things people have gone and bought on a market. That’s what it looks like.

So if I want to go out and buy a /x based on my 24-month forecasts, as policy allows now, no matter what happens after I purchase that, there’s nothing ARIN can do. Okay? You can’t say that just, well, you’ve got to talk about what happens in a year. Vint asks what happens if you go back. It doesn’t matter what happens because there’s nothing ARIN can do. I can’t unbuy the block and ARIN can’t coerce me in any way to sell the block, divest the block. The block has been purchased. And what I do with it now hopefully aligns with the capital that I’ve spent to purchase it.

I understand that if this were a free pool discussion, then Jason’s fraud concerns I would completely agree with and I wouldn’t propose this. I am the policy author, by the way. But you go out and buy what you need. And sometimes you go out and buy what you need for the future, 24 months or not.

And whatever ARIN says or whatever Whois says isn’t going to change that I went out and I bought it and I control the IP addresses.

We have an entire – 8.3, we have an entire very, very relevant transfer section that is based on the 24-month need. What happens in the first 30 days or even what happens in the first year, I don’t know that any more checks and balances is going to change the operational reality of those IP addresses being on equipment, being used for whatever.

Paul Andersen: One moment, please. Recognize John Curran.

John Curran: I’m going to – I don’t have any opinion on what you said one way or the other. But I need to work on terminology a little. So what you call an IP address block and what I call an IP address block, what ARIN uses as a definition of IP address block might be a little different.

So an IP address block in the Internet numbers registry system is an entry in the registry. The person who controls it is the address holder in the registry.

Now, I don’t deny that parties can lock up those rights or release them. ISPs transfer addresses to their customers temporarily or permanently. You can do that. But the ISP, if it’s in the address block as the holder of record, has the rights and can enforce those in court.

So for sake of not confusing people, you want to say that no matter what ARIN does you’re the one who is borrowing or leasing the address space. You can say that, but actually the party you bought them from can enter a transaction with ARIN and so that will change who has the rights.

So it’s only your contract with them that prevents them from doing it. I just want to be very clear that the transaction doesn’t actually complete until you actually have the ability to tell ARIN what’s in the registry. Until then you’re borrowing them or leasing them. So terminology.

Having noted such, just for clarity, if someone shows up with a transfer and we look and we approve the transfer, and then we go out and we say, I’m sorry, you haven’t been using the address block, there’s a very rapid discussion with that company about how to get those addresses utilized. I don’t know if that’s what the community wants or doesn’t want, but that’s what your policy says we have to do. We have to have a discussion with them saying you indicated you’re going to utilize them, you’re not, and you need to come into compliance quickly. So there’s a jeopardy situation. How that plays out, we don’t know, because people very promptly figure out how to get those addresses utilized.

Paul Andersen: Are you in favor or against, or did you not want to state an opinion –

David Huberman: Oh, I’m in favor of the proposal. I think it makes good sense in an 8.3 world where there’s no free pool. 30-day utilization is not realistic.

Paul Andersen: Thank you very much. Front microphone is next.

Scott Leibrand: Scott Leibrand, DLVR, ARIN AC. I support the proposal. I think that in the context of 8.3 transfers in the context of 24-month needs that using 1/24 of the addresses in 30 days would be appropriate. Using 1/4 of the addresses in 30 days is an extremely front-loaded obligation.

To John’s point about people very quickly figuring out how to use the addresses when ARIN follows up with them, I really doubt that corresponds to actual need to use those addresses in an economic or customer sense. It’s putting them on equipment because ARIN says you have to. That’s kind of silly and pointless.

I think this requirement is kind of silly and pointless in the context of 8.3 transfers, and I think we would be best off going ahead with the proposal as written.

I understand Jason’s concern about end run-around needs justification, but I believe that the fact that people have to put down the real, hard cash to get addresses is a sufficient disincentive from them doing anything that would bypass this policy in any meaningful sense.

So I don’t think that that concern is something that we need to have a holdup from moving this forward. If we wanted to have other discussions around ways to deal with justified need in a 8.3 transfer world, I think that’s a very valid discussion to have, but I don’t think it should derail this policy. So I support it as written.

Paul Andersen: Microphones are going to be closed at the end of this next intervenor’s comments. So I would ask that you please approach a microphone if you would like to make a comment or more participation.

Jason Schiller: Jason Schiller, Google, ASO AC. I just wanted some clarity. Would this policy be applied to end users who are on the waiting list or wanted to get on the list? And if so, can the staff tell me the last time an end-user was added, attempted to be added to the waiting list?

John Curran: This would apply to someone who is on the waiting list. If resources come back in, for example, someone returns them or IANA gives us another allocation, we will issue people address space based on this.

But I guess the point to recognize is the last time we received a large amount of space from the IANA, we’re getting diminishing dribbles now based on the returned IPv4 pool. The last time we satisfied six people out of a waiting list of 300. So while it is applicable, it’s applicable to a very, very, very small number of people in the world.

Jason Schiller: Thank you.

Paul Andersen: The microphones are closed. We’ll go to Kevin Blumberg unless there’s another comment online. No?

Kevin Blumberg: Kevin Blumberg. What happens, John, when an organization gets its space through a transfer and doesn’t reach 25 percent? What in the RSA is ARIN’s recourse?

John Curran: ARIN’s recourse provides if you don’t comply with policy, then we can then reclaim the address space.

Kevin Blumberg: So we have a situation now where in the free pool no transactional things occurred financial between two external ARIN parties. ARIN gave the space. You didn’t follow the policy. ARIN took the space back.

Now we’ve got this complexity of party X now works with party Y to do a financial transaction. ARIN’s in the middle of it but then ARIN can go after the fact and yank it because of a policy that was designed for free pool, just to –

John Curran: So just as parties have been very wise not to try to force a noncompliant transfer on ARIN, I’m very prudent when I say that ARIN can reclaim the address block. When I call someone and say we need to get you into compliance there’s usually great compliance. We’ve not yet had to have a circumstance where we remove a block that someone’s transferred and that they have paid their money for and we’ve taken it for the use of the community because of noncompliance.

Generally people are very rational when that discussion comes up.

Kevin Blumberg: So based on that I support the policy and I support it because this simplifies and prevents the head-butting in the transfer market that can cause a conflict that’s not needed.

Paul Andersen: Thank you. With that, the discussion is closed. Let’s thank David Farmer for the presentation and the work.

(Applause.)

Paul Andersen: I’m now going to ask our crack polling team to get into position here. Question is slightly different because, again, this is in a slightly different phase. I’ll be asking for those in favor and again against the Advisory Council advancing the proposal to the next stage at this time. First I’ll ask for those in favor and those against. I’ll just first wait for the go signal.

Just as a reminder, if you can hear the sound of my voice, you are entitled to put up your hand for a yes or no should you so choose.

So, first, all those on the matter of ARIN-2015-3: Remove 30 day utilization requirement in the end user policy and having the Advisory Council advance it at this time, please raise your hand for in favor. Please keep your hand up. Remember which hand you put up this time; you can do the other one next time, try and balance out the workout. A little bit longer. You may lower them. Thank you.

Now all those opposed, please raise your hand nice and high. You may lower it. One moment as we get the results.

Any public service messages, John, today?

John Curran: I think there’s one coming in an afternoon slide, but for those people who may have had challenges getting to and from here, we’re juicing up the shuttle schedules. There shall be more schedules, more shuttles running more frequently and that will help us get to other points in this very beautiful resort.

Paul Andersen: Excellent. On the matter of 2015-3, still in the room – no, I think we went – we changed a bit. 113 in the room, four remote. 117 total. 42 in favor, three against. This feedback is being provided to the Advisory Council for their feedback. Thank you.

(Applause.)

John Curran: We’re coming up on our afternoon presentations. I’m going to quickly bring up Cathy to do the IETF report. I’ll see if we can get that done because we missed her this morning.

Paul Andersen: Not quickly. She always gets squeezed for time.

IETF Report

Cathy Aronson: Hi. So I found out recently that those of us who attend the IETF and are mere observers and then kibitzed about it afterwards are actually called tourists.

I took this self-portrait in December. So I couldn’t help myself. I don’t know if it’s going to be permanently called the IETF Tourist, but I just thought it was hilarious that I’m known as a tourist.

Unidentified Speaker: We think you’ve gone native by now, though.

Cathy Aronson: I used to not be an IETF tourist. I actually used to write stuff, but maybe I will again. We’ll see. I just thought it was entertaining. So I’m the tourist.

Okay. So about the presentation. You guys have all – probably most of you have seen this before. It’s just a little disclaimer.

Before I go to the next slide, this was probably the most popular slide of my last IETF report, and I’ve – in an effort to be more diverse – I’ve included women’s shoes from the IETF because there are some and they’re very stylish.

So there’s some really poorly styled male shoes as well as some really stylish women that also attend the IETF. We’re 9 percent of the population, but we’re mighty. So I don’t know it’s – okay.

Also, I’m not sure if – I don’t know if I consider this to be a highlight of the trip. But Scott Bradner is also retiring from the IETF work that he does, and we all know him from here and we miss him a lot.

But Jari put up the next slide at the plenary, and I couldn’t help myself. This is what the press is saying about Scott Bradner, the mother of consensus. So a round of applause for Scott.

(Applause.)

Vint Cerf: I’m sorry to interrupt. You need to explain that that’s Houlin Zhou, who is the Secretary General of the ITU. You can imagine how welcome he might be in the IETF meeting.

Cathy Aronson: Actually, he gave a really good presentation in Yokohama, though. He’s really well spoken.

Anyway, so thanks to ARIN, one of the side things I got to do while I was at the Yokohama IETF in November was to go to Iwate and give a talk to a bunch of students at my girlfriend’s graduate class. And they loved that I brought them stickers. That was pretty awesome.

Also, for those of you – I’ve decided if there’s something – like there’s some things I’m going to talk about later. If you think there’s something that the IETF should be working on or something you think I should report on, I’m happy to – always happy to try to squeeze myself into one of those working groups if I don’t already. So just let me know. It’s a two-way thing.

I also added a couple of slides that weren’t at the IETF, but yet I heard about them around the IETF and I think they’re pretty interesting. So bear with me. I’ll go as fast as I can. It’s now the Internet Engineering Travel Forum, which I love.

There’s also been a lot of discussions at the plenary at IETF about where to physically have meetings and whether all the venues are welcoming to all the attendees of the particular meetings.

So if you’re interested in that sort of thing, there’s a lot going on with the IETF starting to define what are the criteria we use to pick a venue, that sort of thing.

I’m not sure that – well, anyway, another highlight, there’s a lot of Yang models. I’m not sure how exciting they are, but there’s a lot of Yang models. They’re data models for NETCONF. So we’ll be talking not a lot about them, but there’s a lot of references to them. So if you’re interested in data models, check it out.

This is a link that came up right around the time I left for the IETF, and it’s actually a pretty good article that you could use to describe the IANA transition to your relatives, which some of us have a hard time doing, right? Like, what do you do? Your relatives don’t know what you do. You have to explain it. So check it out if you’re interested. It’s actually a pretty good article.

So right before I left for the IETF in November, I got a question from the community about adding to RFC 1918 space with blocks that aren’t routed like the Department of Defense, the European Department of Defense. And I thought the world had gone mad. So when I went to the IETF, I asked a lot of Internet service providers whether they were doing this. And a lot of them said of course we’re doing that.

And I wrote a blog entry for Team ARIN about this. So if you’re thinking of doing such a thing or if you’re already doing it, you might want to read the blog article, because it’s actually really dangerous. If that blog starts being globally routed and you’re using it as private address space, then you’ll not be able to get to it and you’ll have to readdress really fast.

Anyway, I mean, I see the reason why someone might want to do it. But not a good idea. Anyway, so that was one of my little adventures at the November IETF was to ask people if they are really doing that. And they are. Crazy.

The 2-byte and 4-byte ASN thing – so there’s been a lot of discussion on the PPML about BGP communities and doing routing policy and not having the same functionality with 4-byte ASNs as 2-byte ASNs. And so there are some of us that are really interested in this. Like, if you find Aaron Hughes and I in the hallway, if you have feedback whether we should work on a new RFC in the IETF to expand the expanded communities, because there is an RFC for expanded BGP communities but they’re not exactly quite like the 2-byte ones.

If that’s really an impediment to deploying 4-byte ASNs, then maybe we should work on it in the next five years before we run out of 2-byte ASNs. Anyway, just food for thought, which is really all I have time for is food for thought.

The first thing that happens at the IETF is the IEPG, which is a bunch of operators that meet before the IETF, and the IETF, really most of them don’t know about us.

But we meet on Sunday from 10 to noon for the last 25 years, maybe. And it’s usually the most exciting part of my week. And it happens on Sunday.

So if you’re interested at all, there’s a Web page with all the different presentations and I’ll be talking about some of them. So let’s see. It’s a shoe theme, so if you look at big data and .nl, a lot of the DNS there is being used to falsify, to counterfeit shoes. Which I thought was pretty exciting.

It’s 40 percent of all the border seizures and they’re using DNS legitimately for criminal purposes, which I thought was interesting. The presentation is great.

Also the v6 performance is better than v4 between the mobile LTE network and Facebook, which is pretty interesting.

Let’s see. So there’s a lot of work being done doing DNS over TCP because having that state means that you can have a little bit more stable connection doing DNS. So there was a pretty good talk about that. There’s also a talk about what a router really does, which I thought was super fun at the IETF.

But nonetheless it was pretty interesting. Let’s see. Why is it not showing? There we go. So Geoff Huston gave a really great talk. We’ve seen little bits of it before where he looks at the routing table and sees that the number of prefixes being added is like this consistent rate over time, and the number of ASes being added are at a consistent over time. And it’s like clockwork, kind of amazing.

Actually even with depletion and people maybe using smaller and smaller prefixes the routing table has been growing the exact same way for a while now. There’s some really interesting data that he has in his presentation.

There’s a bunch of high level domains that went away a long time ago and they’re still getting lots and lots and lots of queries. That’s pretty much the summary of this. Like old stuff never, ever goes away. So it’s kind of a bit scary, actually.

So this presentation, pretty interesting. I think there’s like two takeaways. One, inter-RIR transfers, they work pretty well. There’s a little extra work that has to happen. You can’t transfer AS numbers. There’s an interesting slide for those of you who are interested on an interesting description of the ARIN policy process, but if I start to describe it I might not use language appropriate for this audience. So I won’t.

And there’s some information in the presentation about moving the, changing the RPKI, which is the DNS, the security part of moving the address – not the DNS, moving the addresses from one registry to the other. If you’re interested in that you can check out some real life experience.

Encrypted DNS that you’re on. So there’s some information. These are just more talks that were there that I don’t actually have time to go into depth about. But these are the rest of the things that were presented at the IEPG.

So the Sunset v4, my all-time favorite Internet drafts draft ever. Thank you, Lee Howard, wherever you are. Everyone should applaud him, my favorite, favorite: Should we declare IPv4 historic, favorite all-time draft, because it really got – it’s really starting to get people to think about what’s the end game here? People were asking it earlier. When do we decide that v4 is no longer relevant? What are the criteria for that?

It was a very lively discussion, super lively discussion. And we should not give folks the perception that the IETF has lost touch with reality. I’m not sure if that ship hasn’t sailed already. But in the back of the room Geoff Huston and I was – he was looking at drafts that should have been obsoleted a long time ago, like Netbugger 3. There’s a thing – RFC 162 Netbugger 3, that is still not historic.

Neither is Gopher. Go figure. Gopher is like 100 years ago, in dog years at least. For those who don’t remember, it was – yeah, Gopher.

Vint Cerf: Free search engine.

Cathy Aronson: Yeah, it was, like, way before search engines and when dinosaurs roamed the earth. But it’s still not obsolete but we’re going to obsolete IPv4. Anyway, but it’s a really good draft, and it’s really gotten people talking. And if you have feedback about what you think the criteria should be, talk to Lee because it’s a really good thought exercise. Anyway, my all-time favorite.

Okay, v6 operations – I put this toward the front because there’s a lot going on in there and I’m supposed to be following v6 even though I kibitz about a lot of other things. So v6 ops is basically operational things to do with IPv6.

I include little bits from the charter so if you want to read more about what it is it’s always there. And there are actual real charters that are huge. So this was such a cool talk.

So I don’t know how many of you remember but there was a whole, you know, the subnets in v6 are ginormous, and maybe you have five hosts over here but somebody does a port scan and makes all your network roll over and there’s all these drafts about that.

But this guy he’s doing research with these trees looking at where the address space is so that you can, like, find where the address space. And I don’t know if that’s really such a great idea to help the hackers.

But it’s also a really good idea to figure out, like, where the address space is in all these humongous subnets that it might be all over here, over there. And it’s really interesting talk that he gave about that. I was fascinated.

He took a big tree. Anyway, it was awesome. Let’s see. What’s next?

There’s some drafts going on about whether it’s better to have a v6 host as opposed to a whole bunch of hosts in the whole v6 prefix, and whether that facilitates new functionality. And it looks like one of the guys that works with Dan, John was talking about how they’re actually working on this at Comcast.

And whether this is a good model for v6 over Wi-Fi. Anyway, it’s pretty interesting stuff. And the draft that Vint and some other folks wrote is moving forward. It seems to have a lot of support. I think it’s going to probably end up being an RFC, which is all about host addressing and multiple addresses per host, and that sort of thing.

This is an update on v6 deployment at Facebook that they presented. There’s still quite a few issues. And as far as I know, aside from this, I don’t think that some of the applications a lot of users use. I don’t think Skype uses v6 and stuff like that. So as we keep moving forward still lots of things need to happen.

This is all about enterprise design choices for v6. There’s a draft that’s moving through the process about that. So if you run an enterprise and you want to check it out. They’re always looking for people to review the drafts.

The thing that’s important on this draft for everyone here is that there’s a lot of discussion in the IETF right now about provider-aggregated or provider-independent address space. And I’m not sure I’m really comfortable with Internet drafts specifying PI or PA space. But they’re starting to really talk about it.

And I think as a community we need to be paying attention to that and speaking up that an address is really, from a standards point of view, in my opinion, is an address is an address. And whether it’s provider aggregatable or not, I don’t know, I’m not sure. I’m getting my head around that.

So I’ve been kind of following along with that to see how it goes. But recommending PI space, that really has an impact on us as a registry and the routing table.

So LACNIC, a fellow from LACNIC gave a talk about v6 deployment in South America. And there are four countries in South America that have v6 to the end-user. And some of them not quite to the end user, Bolivia Equador, Peru and Brazil. So in Argentina, for the IETF v6 connectivity, there was a tunnel because there’s no v6 in Argentina. So there’s still a lot of work that needs to be done down there with v6 deployment. It’s kind of shocking to me actually.

And they have a whole metric by gauging the planning stages of all the different countries and how far along they are, whether they have any infrastructure and that sort of thing. It’s a really interesting presentation.

More of – yeah, this is, we’re just going to skim over this. This is stuff I’ve talked about in many other presentations – extension headers. So 6man is more of a working on the v6 specifications to make it work. And I don’t have a whole lot.

There’s some drafts going on through 6man, somebody actually went to the mic and said, I’m not sure, I don’t want to misspeak but I’m going to go look it up before I say anything, which was a shocker, just a shocker. So he did. He went and looked up to make sure he wasn’t asking the wrong question.

Nobody ever does that at the IETF. But he did. He was super nice.

Let’s see. They’re working on taking all the real world experience and updating the IPv6 specification itself to look at where we’ve come the last 10, 15 years, and then doing a new rev of the spec and this is what all this is about. There’s four different drafts they’re updating all at the same time to try take everything we’ve learned so far and put it back into the spec.

Let’s see. This is a draft about – there’s a lot of problems with MTU varying packet sizes on networks because v6 is so much bigger. They’re looking at ways to negotiate to make the MTU bigger so things don’t get as fragmented.

Homenet, my very favorite. They’re working in Homenet to automate the home networking environment. I’ve talked about it a number of times with ridiculous diagrams and multiple routing protocols and all kinds of stuff.

So this is what’s going on in Homenet. They picked a brand new routing protocol called Babel or Bay-bel (pronounced), depending on who you are, to be in the Homenet.

I’m still really sort of on the fence about that. And then of course our quote about the Compuserve of things. That’s probably why Vint is laughing. Not really sure.

But the judge decided that Babel is mandatory to implement to as experimental. Not sure on exactly what that means, but more on that later.

And then there’s this – anyway, some of this stuff, this is all about Wi-Fi roaming and v6. So they’re writing.

They took this protocol that no one is actually using called Babel, and they’re going to put it in home network.

So they’re looking at, because it’s not really specified. It’s not an RFC. So they’re looking at what does Homenet need so Babel will work in home networks.

I’m not even really sure why they would pick a protocol that no one is using yet, but it’s supposed to do source routing and everybody seems to want that.

I feel like it’s not ready. That’s my personal opinion there. There’s a naming architecture for Homenet. And that’s one of my favorite quotes of: My host is named banana.Homenet; how do we secure the DNS and how do I know that you’re not me? So they’re still working on it. I don’t know how many people are going carry their host to their neighbor’s house. But apparently that’s a big deal.

More on the naming architecture. These are some more drafts that are going through Homenet. So there was actually, they’re taking Babel now and they’re going to try to make it an Internet standard. And there were a bunch of guys who presented who said, I implemented that in a day. I implemented it in two days. And one of the developers sitting next to me you can write it in a day but it takes a lifetime to debug it. That’s pretty much true. We’ll see how it goes with Babel in the home.

There’s more information about it. It’s a distance back to protocol not unlike rip which we probably should be using.

Sorry, I’ll stop. So there are multiple implementations. I’m still on the fence about it.

Okay. So the other thing I’ve been following at the IETF is human rights on the Internet, how protocols facilitator impede human rights on the Internet. I think it’s absolutely fascinating because I never really thought about it before going to the IETF.

They made a movie. They interviewed a lot of folks in the community and they made a movie that I have a link to in my slides. I think it might be on the next slide, about that very topic. It’s actually really good.

The cast may not be as diverse as one might hope, but the film is interesting. And it’s a good thought process of whether the freedom of association and those sorts of things are facilitated or hindered by the net.

So you should check it out, because it actually is really interesting.

I need to figure out why my slides go off the bottom. Maybe I put too much stuff on them.

This guy is so cool. He wrote a programming language in Arabic. Think about that. It’s not ASCII.

And he looked at all the different things that break if you try to have a programming language if a non – I’m grasping for the wrong word. But anyway in a language that is not Latin characters. Thank you. I couldn’t quite grasp it.

And he also has a really cool blog and one of the titles of one of his entries was, nope, still not Arabic. Like there’s all this stuff out there that looks like Arabic but it’s actually just gibberish.

And he gets these people that come across his site and they’re so excited, they’re young kids. And they speak Arabic. And they’re so excited they might get to program in their language. And they can’t. It didn’t actually work. The whole process didn’t work because the whole computer, everything is American English and ASCII. So they have to actually learn a whole other language to become a programmer.

Interesting thought process, really, the whole human rights thing. But anyway I’m going to start following his blog because I think it’s awesome.

This is multi-stakeholder process document that somebody wrote as their thesis. I’m still halfway through reading it. It’s pretty interesting. Check it out. It sort of analyzes what we do here, the whole bottom-up process that we use to set policy and what it means, and the ins and outs of the thing. It’s pretty cool.

The IANA transition with respect to the IETF, we do quite a bit of talking about it here in ARIN, is mostly done. They’re just working on intellectual property rights of who owns what, and the interaction between the trusts and the IETF and the IANA and the trademarks and that sort of thing. But mostly they consider it to be well on its way, which is kind of nice. I think we’re kind of almost there – here too.

There was a BoF about intelligent transportation systems, which terrifies me. Like, your car is talking to the car next to you. Can I follow you? How fast are you going? Kind of creepy.

And then the network in your car, with all your passengers talking to their PDAs because they can’t actually turn across and talk to each other. They’ve got to use their computers to talk to each other.

So there’s a bunch of use cases. There’s some documents. I’m not sure I really want that in my car. I like my adaptive cruise control. But I don’t want to talk into your car. I just don’t want that. Can’t go there.

There’s a draft that Jari just wrote, and this is sort of the non-standard bit of IETF, which is pretty interesting. They’re doing a lot of work on diversity and all kinds of stuff, and he wrote an interesting draft about all that.

So this is an interesting, some interesting work that’s starting to look at all the different ways that we use names in the Internet that aren’t necessarily in the DNS, like.onion for Tor which is the big encrypted network of privacy anonymous networks that is used a lot, and how to incorporate those and make it so that there’s not just a ton of failed DNS attempts, for example, and that sort of thing.

There’s a lot of work being done. They might form a working group, but right now they’re just sort of talking about what are all the different names that – naming things that are used in the Internet and what do we do with them and how do we reconcile them? Because there’s a lot of nonexistent domain stuff that’s happening that shouldn’t be in the DNS.

This is policy abstraction language. And guess what? There are Yang models in there. There’s a whole lot of Yang models. I went to this on the way to something else. I am not going to talk about it very much. There’s a lot of work being done to like abstract data information on the Internet – some drafts, why it’s valuable. I’m not really going to talk about TEAS too much but there’s a whole traffic architecture and signalling work going on, traffic engineering, and there’s some Yang models there, and some drafts that are happening in that area. Not very IPv6 and secure telephony. I think I talked about that a while before. So there’s some drafts going on there.

So GROW is the global routing operations group which I like to follow because I used to do routing, a lot of routing. And Jared has a really interesting draft. I’m trying to make BGP come up and behave and not just start advertising everything by default. And fixing some things like that, so that you don’t accidentally announce, like, the whole world when you shouldn’t. Maybe you do that on purpose but not by accident. That would be kind of nice. And there’s a work being done on a blackhole BGP community to mitigate different kinds of attacks and things.

I went to a meeting early one morning. Early in Argentina is before 10:00 a.m. because the meeting didn’t start until 10:00 a.m. because you can’t get breakfast before 9:00 a.m. and you can’t get lunch before 12:30 or 1:00 and dinner never ends until midnight.

Anyway, I went to a meeting about – so the IETF is different than ARIN. At the IETF they do meetings in other regions to facilitate the people who actually do IETF work in those regions. So not as outreach but to go, oh, well, there’s a whole lot of people that do work in China, for example, so maybe we should have a meeting in that region to help those people not have to always travel to Minnesota, because we used to have a lot of meetings in Minnesota.

So we ended up with a meeting in Argentina, because a lot more people from South America and Latin America had started participating so they had a meeting in Argentina. There’s a group of folks that are trying to make a meeting happen in Africa. And in order to do that they need to get a lot more participation from Africa. So they had a meeting to talk about how do we do that.

And there’s all the remote hubs that are happening so you can participate virtually and there’s a really, really good remote participation at the IETF, and people actually asked their questions.

You can see their face and you can hear them talk, which is really nice. So I went to the meeting, and it was really interesting. I was on the Mailing List now so we’ll see what comes of it.

But down there they’re mostly network operators. They’re not really hardware developers at this point in their history. So we always need to get more operators involved in the IETF.

So really trying to work on ways to make that happen. So we’ll see how that goes.

I was really disappointed to miss Andy Newton’s talk at SIDR, but I was listening to the talk about IPv6 deployment in South America at the same time. But Andy has a draft written with some other folks and he gave a talk that had a quite lively discussion at the end that I mostly missed unfortunately.

These are some of the other things that are going on in SIDR, which is Secure Inter-Domain Routing. I don’t know if anybody who listened to Andy’s talk wants to comment about – oh, John Curran.

John Curran: So the engineering teams of the five RIRs put together a draft regarding a SIDR Trust Anchors or RPKI Trust Anchors. Basically we’ve noted in the past that the validation algorithm for RPKI is fragile in the cases of overclaiming. And instead of validating – invalidating just the overclaimed resource it invalidates the entire set of resources signed by that certificate.

So when we’re doing transfers we end up with certificates that have the potential that as we’re moving something to another RIR, two RIRs may be claiming the same resources. That would invalidate all the resources under an RIR certificate authority.

Because – and we have pointed this out to the IETF and they have interesting reasons why they don’t want to change it. RPKI is a proper subset of PKI and PKI has rules for how things are trusted, and this would require either changing those rules or making an exception for RPKI.

So to make RPKI less fragile while we’re deploying it – because we’re supposed to be improving the Internet, not breaking it – the RIRs will all work on a trust anchor that is universal. It’s a 0/0 trust anchor, all five RIRs.

Each of us will only sign our own resources, but there will be no chance of an invalid certificate where and RIR is overclaiming a resource and therefore invalidating all of its customers.

We said this is the only way we see that RPKI is actually deployable and wrote that up in a draft and provided it to the IETF where it had a warm reception at the SIDR working group. But they understand and in fact there’s discussions now about the working group taking on the document as a working group document and so that’s a good thing. We’re just trying to maintain the communication between the people who work on the protocol with the people who actually have to make it work for you.

And it’s an ongoing process, I guess.

Cathy Aronson: Where are we? There’s the information about the draft. Thanks, John.

So here’s some references, how to get involved if you want to, that sort of thing, upcoming BoFs. There’s also a really great video about how to get involved and the culture clash of interacting with IETF people. That’s pretty good if you’re ever going to go to an IETF.

If you’re a woman, and you’re going to the IETF, there’s the IETF Sisters. And if you’re a man, all the Mailing Lists are for you anyway. So it’s all good.

We have a great group of women that get together now. There’s like 40 of us sometimes all in one room. It’s really cool.

Does anybody have any questions? This is from my neighborhood last Monday night.

Jason Schiller: Jason Schiller, Google. ASO AC. One comment, one question. My understanding with regard to Lee Howard’s some techy’s Word draft is to stop doing protocol development for IPv4 and only do protocol development for IPv6.

Cathy Aronson: That is one of the intents as I understand it. When you hit make a draft historic, it really pretty much stops most of the work. The IETF can still do whatever it wants to do. So if somebody writes a draft and it gets past the powers that could be, it probably could still happen. But it’s sort of phasing it out, so to speak.

Jason Schiller: And I also noted in your slide there’s some discussion about ULA. Was ULA-Central ever a topic of discussion? If so, I think this community would be very interested.

Cathy Aronson: I don’t recall at this time. Certainly I think that it has been discussed. But, Alain?

Alain Durand: Alain Durand, ICANN. You had a slide on squatting on RFC 1918 space. Would you mind expanding a little bit on it?

Cathy Aronson: Expanding on it?

Alain Durand: Yeah, I was not there, so –

Cathy Aronson: Oh, yes, certainly. Before I left for the IETF I was asked about what the best block would be to pick to use of the nonrouted /8s to add to RFC 1918’s space, like net 20 or net 30, and I didn’t know people were doing that.

So I spent a bunch of time at the IETF asking about it and a lot of service providers are doing it. And I wrote a blog about it for Team ARIN because it’s very concerning because, A, the blocks don’t belong to you; B, if somebody starts globally routing them you have to instantly readdress everything on your network that’s using that address or no one will be able to get to it – will be able to get to the legitimate users of the address space. So, but it’s being done a lot, a lot.

On my blog entry, I Googled it. I’m not going to name names but I posted a ton of online stuff that people had talked about using it. Or there’s a big, there’s also a big conspiracy, people do a trade shot, they see the Department of Defense address in their trade shot, and they think they’re being surveilled, even thought it’s just somebody using address space of RFC 1918 space.

But Team ARIN, my blog has a bunch of links you can read about all the different service providers that are using this address space and basically squatting on it for more RFC 1918 space. I’m not sure if it answered your question.

Alain Durand: Yes, thank you. And follow-up question. For people who are proposing to write a draft to say which blog to squat or conversely are there a proposal to write a draft saying is squatting considered harmful?

Cathy Aronson: I think it would be awesome if there was a draft that said it was considered harmful. I also think, though, that if a bunch of service providers got together and went to the U.S. Department of Defense or one of these organizations and said, you know, it’s to your benefit to announce that you’re never going to globally route this because the more people who are using it as squats based, the less likely it is that you’re going to ever be able to get to the real addresses on that block.

So, if they’re never really going to announce it, it’s actually to their benefit to announce that they’re never going to announce it. But now that address space is worth money, there’s a big block everyone’s been using, it’s a European block that was going to become publicly available on the routing table, and everybody was scrambling to try to move out of it. So I don’t know if that happened or not. So, I think it would be, yeah, an operational draft might be a great idea for that.

David?

David Huberman: David Huberman, Oracle and a former squatter –

Cathy Aronson: I wasn’t going to call you out.

David Huberman: This is one of these things where, if you’re an IETF outsider like I am, you look at the IETF and say, what have you been doing all these years? National telecos in other parts of the world outside of the United States and Canada and cable companies now in the United States get it all over the world.

And large enterprises, enterprises – network is like really important in the enterprise now. Didn’t used to be, right? You have these really large enterprises and they happen to have an architecture that’s a single AS. And you put all these different users together and you realize RFC 1918 was never large enough. It was never going to scale to this.

So, rather than saying maybe it’s a really good idea if the IETF puts some information out there that this is a bad idea, maybe we ought to concentrate those efforts on finding an engineering solution for folks who need to bootstrap to v6 but have literally run out of 1918 because right now squat space is it. D is no good and E doesn’t work.

Cathy Aronson: Right, but v6 does, but it’s another hurdle.

David Huberman: It’s a big hurdle. At the scale you’re talking about, it’s years of effort and it’s years of capital and we’re going to get there. But what do we do today?

John Curran: I’m going to close the mics very shortly for the sake of everyone but if you’re in now, in the queues that’s fine.

Cathy Aronson: I’m excited to have a line at the mic. It’s the first time.

Kevin Blumberg: Kevin Blumberg. Just to expand a little bit on that. The warning shot has already happened with the squatting space. 20 years ago when somebody said in a boardroom, let’s squat on this. It’s low risk.

Well, the UK government had started selling off their IP assets. And there’s already been known instances where this has affected people who have squatted this space internally. So that low risk in the boardroom from 10, 15 years ago has now become a very high risk to organizations.

Cathy Aronson: Right. Vint?

Vint Cerf: You know, I wonder whether the Defense Department might decide to use the address space for routing drones. You might not want to be in the target area of those addresses.

Owen DeLong: Owen DeLong, ARIN AC, Akamai. For those whining about RFC 1918 is not large enough, guess what? V4 is not large enough. Move on.

Cathy Aronson: Anyway, but it is a bad idea. I mean, like – yeah.

John Curran: A round of applause for Cathy for her report.

Cathy Aronson: Thanks you guys.

(Applause.)

John Curran: Okay. Amazingly I’m going to ask for a show of hands. If I give you a ten-minute break, then you come back in and we’ll actually get out of here on time. If I give you a 30-minute break we’re going to go past 4:00. Everyone in favor of a ten-minute break raise your hand.

Everyone in favor of a 30-minute break raise your hand. You can stay late if you want. We’re going to have a ten-minute break. You’re broken. Get out there. Get back here in ten minutes.

(Break.)

John Curran: Among the people who came back, is Leslie Nobile in that list? Very good. Very good. Leslie, you’re up. We’re resuming. We have two presentations. One is Leslie on the importance of Whois accuracy. And then we’ll have Nate Davis, our operations officer, give the Software Development Update.

The Importance of Whois Accuracy

Leslie Nobile: Okay. Everyone, good afternoon. I’m going to talk to you about the importance of maintaining Whois data, the importance of Whois accuracy. This is one of my main focuses in my new role.

So I’ve been working on a project right now about Whois accuracy across the RIR system. And I recently wrote a blog about it. And I’ve decided to maybe bring it to you all and talk about it here, because there’s some important data points I’d like to highlight.

So I have some very basic facts about Whois. I’m sure most of you know this. But I just wanted to sort of start by talking a little bit about what Whois is.

So it is a query and response protocol. Some people think it’s a database. It is actually a protocol. And it’s used for querying databases that store registered users or assignees of an Internet resource.

And that Internet resource could be IPv4, IPv6 or an Autonomous System number or a domain name. So RIRs use Whois, and domain name registries also use Whois.

Whois is used by lots of different people. It’s used for good and it can be used for bad. We’re actually going to talk a little bit about both of those things. It’s used by network operators. A lot of you are network operators. You know what you use it for.

You like to know who is running networks so you check Whois. It’s used by a lot of researchers. They produce lots of different data and reports and studies. It’s used heavily by public safety officials. And that is law enforcement, global law enforcement uses Whois quite often to try to find criminals.

And it’s also used by many other community stakeholders for a variety of reasons. And as I said some good and some bad.

And the thing about Whois, ARIN’s Whois data, is that it is the responsibility of the registrant to ensure the accuracy of their registration records. It’s not ARIN’s responsibility. It’s the registrant’s responsibility.

So we don’t often go after users to update their data. There’s only one instance, and I’ll talk about that in the presentation where ARIN is actually pursuing registrants to update their data. And that is because of a policy.

So why is it important to maintain accurate Whois data? I just threw out a couple of reasons that came right to the top of my head. Accurate data helps keep the Internet safe and secure. Everyone knows who is using Number Resources, who is responsible for the Number Resources.

It helps to protect your Internet Number Resources from being hijacked. When records are out of date, hijackers are looking just directly for that type of information. They want to see records that are sitting dormant for years. They love it.

It’s actually required under your ARIN Registration Services agreement, the RSA and LRSA. There’s a requirement in there in the terms and conditions that you must maintain accurate data and notify ARIN when things change.

And quite honestly it’s the right thing to do. We’re all global Netizens, and it’s our responsibility as users of the Internet to keep our information accurate.

So ARIN is seeing some different trends recently that are affecting Whois data. So this isn’t actually new, but we’re seeing a resurgence of this. Registration records that have not been updated and maintained have always been the target of hijackers. But with this new IPv4 market, transfer market, the hijackers are really actively seeking out resources that have not been updated in years.

So they have this whole series of checks that they do. They’re looking for the dormant records, those that have not been updated in quite some time.

They are looking for expired domain names. They’re looking for companies that are out of business. They’re checking routing to see whether resource is being routed.

So they have all these different checks they do. And they’re doing this to determine whether the resources are actually in use. So if they determine that they’re really not in use or they may not be in use and the registrant is no longer viable, they attempt to take over the organization record and its related resources by pretending to be the actual registrant. They’re quite bold these days and they’re getting a little smarter.

In the early days they weren’t quite as smart and we were stopping a lot of them. These days, they’re a little more sophisticated. We see lots of hijacking rings. There’s a lot of them that work together and they’re not afraid to sign their names on things and pretend they’re someone else and to sign names on sworn affidavits, et cetera, et cetera. So they’re pretty ruthless, I guess.

So ARIN catches a lot of these but there are times that we don’t catch them. We just can’t stop everything. And like I said, they’re a little more sophisticated than they used to be. So if they’re successful, the result is that the registrant loses control of its resources and potentially its organization record and its point of contact record as well.

So looking at the hijack target, the typical hijack targets, that would be mostly the legacy IPv4 networks, those that were issued prior to the establishment of ARIN and that typically don’t come in update the records with ARIN. And one of the reasons, there’s many reasons, but these are the records, the networks that are far less likely to have at least one validated point of contact associated with a record. So I need to explain what a validated point of contact is.

There’s a policy in ARIN that requires every single registered point of contact to receive an email from ARIN every year and we require them to validate their record, to say, yes, this is good, this is still good, or, no, it’s not good and I’ll come in and update my record.

If they don’t validate, they don’t respond to our request within 60 days and ARIN determines that they’re not valid and we can’t find them, we actually mark their record publicly in Whois as not validated. That’s the policy. That’s what it tells us what to do.

Now I’m going to look at the pie charts down there. We have a total of over 50,000 network records in ARIN’s database. 26, on the left pie – 26,776 of them are ARIN-issued networks. It says nonlegacy, which is probably not the greatest terminology. These are ARIN-issued networks.

So of that 26,776, 89 percent of them have at least one validated point of contact associated with their network record and 11 percent of them have no validated point of contact at all, which is actually pretty good percentages when you look at the totals. But if you look over to the right at the 25,218 legacy networks that are registered in ARIN’s database, 55 percent of them have no validated point of contact at all, and 45 percent of them have at least one validated point of contact. Actually I think that’s better than I expected. When I ran the data I was quite surprised.

Probably the more interesting thing at the bottom in asterisks, those legacy networks with the validated point of contact in the darker blue pie on the right where it says 55 percent legacy network, there are 345,837 /24s within those network records, individual /24s. And in today’s IPv4 transfer market that’s a lot of money, and that’s exactly what the hijackers are looking for.

What can you do to protect your Whois data? Obviously we want you to come in and update your data with ARIN. When things change, come in and update your record, whether that’s your Org record, your point of contact record or your resource record.

One of the more important things to do is to make sure ARIN knows if there’s been a merger, acquisition, transfer, or name change. What we see at ARIN is that a lot of companies who do mergers and acquisitions, they forget about ARIN. It’s understandable; they’re running a business and making the money. So they’ll come to us five or 10 years later to update their record and say, oh, by the way, I have this transfer. I merged with this other company.

That means that those records are – the organization records and resource records are sitting out there completely stale for years, which is bad. So it’s stale data. But the other thing is with the transfer market a lot of companies come to us to do these transfers and they’re unable to because the registration records are incorrect. They’re still showing the name of the old company instead of the new company that they merged with. That puts sort of a damper on pursuing transfers in the market.

The second thing you can do, and we’re going to talk a little bit about this in the following slides is to respond to ARIN’s annual point of contact validation request. So that was what I was just talking about. It’s the policy, we send an email to people and we ask you to confirm your registration information or your point of contact record.

And we actually give you a couple of different options in there. You can either confirm by clicking on a URL, which a lot of people don’t like to do, but as soon as you click the URL it validates you, you’re done. Or you can just write back the word “correct” and then ARIN will go ahead and validate your record for you.

Or you can go into your own registration record via your ARIN Online account, through our Web portal, and update your own data and that immediately validates you. So you have sort of three options. Yeah, so those are the three options.

Looking at POC validation statistics. I’ll go down to the data first, and not that top thing. So on the left-hand side, it shows the total number of – there’s 228,647 indirect points of contact in ARIN’s database. An indirect point of contact is one that was – it received a reassignment from an upstream ISP. So an upstream ISP is typically registering these points of contact and they don’t have their own resources through ARIN. They have them through an upstream ISP.

So out of the 228,647 indirects, 90 percent of them have not validated their point of – 90 percent have not validated their point of contact records, and only 10 percent have. And mostly it’s because they don’t know who ARIN is. They don’t understand what they’re doing. They don’t know why they have to validate. They’re not receiving a lot of information from ARIN or their upstream about it.

So we’re trying to put some, make some changes there. If you look on the right-hand side, 52,004 direct POCs are in ARIN’s database. 57 percent of them have actually validated their point of contact record and 43 percent have not. Now, I don’t think those numbers are great. And I realize it’s because those direct POCs include legacy resources. So anybody who received legacy space, if they received a direct allocation or assignment from a predecessor registry, they’re called a direct POC. So that’s including legacy and ARIN records right there. And legacy, as I said, tend not to update their records as often.

David, yes?

David Farmer: David Farmer, University of Minnesota, ARIN AC. Those percentages, is that currently valid POCs or ever validated?

Leslie Nobile: Current. It’s current data.

David Farmer: Okay, cool. Thank you.

Leslie Nobile: Uh-huh. What’s not accounted for here, and I should probably mention, is there’s sort of a population of POCs that are not receiving this POC validation. And those are what we call orphan POCs. These are points of contact who are not tied to any resource whatsoever.

Typically those are reassignments that were done by an upstream ISP, and they registered their points of contact in anticipation of issuing them space or putting in a reassignment record for them, or they put in a reassignment record for them and then they deleted it and gave it to someone else but never deleted the point of contact.

So there are – there’s over 250,000 orphan POCs in ARIN’s database. It kind of mucks up the whole process. So we’re working on a project, I am, to start eliminating orphan POCs. And we’re setting some business rules, et cetera. And that hopefully will clean up the data just a little bit.

Okay, the POC validation process enhancement. As I said, not everybody loves the POC validation process. It’s fairly simple but they just don’t get it. So we’re trying to make some improvements. That’s one of our projects.

One of the first things we’ve done, and we’ve actually already done this three times, and I think our latest message was the winner, I hope. We’re improving the POC validation messaging that we send out annually to people.

And what we did was we worked with Registration Services and we tried to identify all the points of confusion, and then we rewrote the message so that it addressed every single point of confusion. We think we’ve got that down.

We’re also improving the messaging we send to all newly registered points of contact. We used to send a blurb saying, oh, you’re registered in ARIN’s database without explaining anything to them. Now we’re telling them who ARIN is, why they’ve been registered in the database, who they were registered by, and to expect to receive an annual POC validation message to make sure that their record stays accurate.

So we’re giving them more information and hopefully they’ll be just a little more clued in.

We are creating a new POC consolidation functionality. And we see that ISPs tend to – each time they assign a network reassignment to a customer, they reregister a whole new POC in the database. So sometimes we see five, 10, 20 POC handles for the same person, and there’s no easy way to consolidate them right now. So we want to make a tool and make it easy for them to have one record.

Because right now if they have 20 handles they’re getting 20 annual POC validation messages. We want to simplify things for them. One of the big things we’re doing for ISPs, we are going to make it easier to manage their reassignment data. We have something called SWIP. That’s our reassignment tool. It doesn’t do a lot. It just adds a reassignment. Doesn’t do anything else.

So we’re working on enhancing that, and we call it SWIP-EZ. That’s coming up in Q4, so we’re adding more functionality to that SWIP tool to make it easier for ISPs to not only to add reassignments but to delete them and to delete the POC if they’re no longer valid. So that will make it much better.

One of the things I’d like to do and still talking about this one – and there’s a few other things, but these are a few highlights – we want to send an annual POC validation summary to ISPs so that they remember how many POCs they actually added themselves through their reassignments and that they’re aware that this annual validation comes up, and that they should probably be communicating with their customers, or they should probably be coming to ARIN if those are no longer their customers and deleting those records. So we hope that will spur them a little to think about that.

What are some specific steps you can take to keep your outdated registration records updated? Well, the easiest thing is to log into your ARIN Online account. As I mentioned, that’s the ARIN Web portal. That’s the way you interact with ARIN to update your records. If you don’t have one, you can create a new one.

And once you get in there, there’s a whole left-hand navigation bar, and it gives you all kinds of options, and you can update anything right there by going through ARIN Online.

If you don’t understand the process or if you have any questions, you can send questions to ARIN by the Ask ARIN functionality in ARIN Online, or you can send an email to hostmaster. We still answer those.

And we’ve actually made it easy to report inaccurate Whois data. This came through our customer suggestion process actually. And they wanted to have a place where they could – they knew if there was bad data, they wanted to be able to report it to ARIN. So we put up a simple Web tool. It’s on our home page. It’s called the Whois Inaccuracy Reporting. And we would love to – we get emails – we get little reports all the time and we investigate them. Or you can send an email to hostmaster@ARIN.net, but the Whois inaccuracy reporting is the best way to do it.

So does any of this work? Are these actions effective? Actually, they are effective. And this is one of the main reasons. Any update you make to a Whois record becomes immediately reflected in the last updated field.

So no matter what you’re updating, whether it’s your POC, your ORG, your resource, that registration record then shows as last updated with yesterday’s date, for example. And this lets potential hijackers know that the POC and its associated organization are current, active, alive and well. Somebody’s out there paying attention, watching things.

And it can be a significant deterrent to hijackers, they don’t want to mess with anything that’s been recently updated and watched. They want to look for things that are not being watched and people have forgotten about.

The other thing relates to the Whois inaccuracy, ARIN staff does investigate all that inaccurate Whois reports, and we do try to obtain some updated information. So we are working this.

And that’s all I have. Are there any questions.

John Curran: Questions?

Scott Leibrand: Scott Leibrand. Do you, when you send the information to the newly created indirect POCs, do you give them a chance to validate their POC right then, or do you wait til – arbitrary timeframe?

Leslie Nobile: They don’t need to because that’s their first entry into the database –

Scott Leibrand: But they didn’t make it. Somebody else made it for them.

Leslie Nobile: Right, but it’s valid until the following year. It’s done annually.

Scott Leibrand: From your perspective it may be valid. From the perspective of the other person who just got added it may not be.

Leslie Nobile: It’s something to think about.

Scott Leibrand: So I would suggest if you’re going to contact them any way, you put in their first POC validation as that message and ask them to go through the process of telling you whether their ISP is making up crap or if it’s actually accurate.

Leslie Nobile: Okay, that’s an interesting thing to keep adding. Okay. Thank you. Jason?

Jason Schiller: Jason Schiller, Google. On the orphaned POCs topic, one of the things that I noticed, which is difficult and people often get wrong, is they’ll do a reassigned simple, which –

Leslie Nobile: A what?

Jason Schiller: A reassigned simple which then creates a POC, and then they’ll decide, oh, I made a mistake, it’s the wrong block, delete that block. And then a year later when they’re no longer a customer delete that block, and they never go back and remove the POC.

So, is your tool going to say you just removed the last resource for the following POC. Do you want to delete the POC as well? How is that going to work?

Leslie Nobile: Well, we’re working on the business rules right now. We’re trying to not, to affect any records that might be viable. So we’re putting at least a one-year time limit on it. We may go to two years if it hasn’t been updated in one year or two years.

But we’re just looking at – we’re just sort of developing those rules now. But we’re going to be extremely cautious.

John Curran: It would be much better for ISPs to be able to delete the associated POCs that limit their reassignments, so that’s our first policy.

Jason Schiller: I think what would be helpful to me is when I delete the resource record and have created an orphan POC, to let me know at the time that I’m deleting the record that I’m creating an orphaned POC and make it very easy for me to delete that as well without having to dig in and figure out who that POC is and then delete it as well.

Leslie Nobile: Right. One of the things that SWIP-EZ is going to do is it’s going to allow you to do that and determine that right then. SWIP doesn’t do any of that now. Once we develop SWIP-EZ, it’s going to allow you to delete anything you need to right then and there.

Jason Schiller: Will the template also be modified so I can say if this is the last block remove the POC as well?

Leslie Nobile: I don’t know about the template. We haven’t gotten there yet. That’s Q4. Can you ask me at the next meeting?

Jason Schiller: Sure.

Leslie Nobile: Thanks, Jason.

Cathy Aronson: Cathy Aronson. I just want to say that for all the years that we’ve tried to make policy to make SWIP – to make the database better, I just think this is awesome. I just wanted to say that. I think this is great. And it’s going to make such a difference.

Leslie Nobile: Thanks, Cathy.

Janine Goodman: Hi, Janine Goodman with Avenue4. I want to make a comment on your comment about how legacy holders are not make the 8.2 requests, which is also leading to inhibiting the transfers. And one of the things we’re seeing in having conversations with these sellers is that one of the reasons they’re not going forward with the 8.2 isn’t necessarily an inertia issue so much as one of the things they’re asked to do when they do 8.2 is to sign the RSA. And one of the things in the RSA is language that talks about property rights and not having property rights, and so they’re very concerned about basically giving up something that, granted, has just not been decided yet in a court of law. So it’s an undecided issue and they’re not interested in signing contracts that give away rights.

I’m wondering if to kind of overcome this issue of having, to try to encourage legacy holders to go through the 8.2, whether there’s been some thought as to how to encourage them to go through the process.

Leslie Nobile: Good question. John’s got it.

John Curran: First thing to do is, if you haven’t looked at the legacy RSA since it was issued, the RSA and Legacy RSA earlier, last year we completely revised and it’s clearer in the rights that are provided and the rights that are disclaimed. And I would ask you if you haven’t looked at it in the last six months, you probably need to look at it again.

Second point is that you can, if you’re a successor organization you can reclaim your organizational ID. We do require people to enter into an LRSA if they’re going to be in a situation where they’re not transferring an entire block. But it is possible to update your information in the ARIN registry as a legacy holder without signing an RSA. Depends on the exact circumstances. And so I guess it’s not universal that you’re going to have to sign an LRSA. You’ll have to sign an LRSA when you finally do a transfer, because we need the indemnification portion of that.

We’re actually looking at that to see whether or not that’s necessary. In some cases, if someone’s transferring an entire block, we have instead had an indemnification and an officer letter because they’re transferring the whole block.

When they’re done there’s no reason for them to have an RSA with us because they have no resources. So it’s not universally true that you’re going to end up signing an RSA if you’re doing a transfer, and the LRSA is actually much friendlier to rights. We incorporated many pages of comments from this community into this LRSA.

Janine Goodman: I was actually looking at the RSA before I came up here, and maybe it’s interpretation, but what I saw in Section 7 was that Number Resources are not property and the holder will not have or acquire any property rights. And I think that’s the language that’s in there that gives legacy holder pause.

John Curran: That language is very clear. Section 2 outlines the rights you have. It does say you have the right to be assigned to the – you’re associated to the block, you’re the only one associated with the block, and you can transfer those rights to others, comma, in accordance with policy.

None of that should be a problem. They’re very clear rights, and they give you what you want, unless you intend to transfer contrary to policy. If that’s your intent, I actually can’t help you, but neither can this room.

Adam Gosling: Hello, I’m Adam Gosling from APNIC secretariat. I don’t have a question. This is more of a heads-up. In our last meeting in Auckland, prior to that we had a policy proposal regarding Whois data quality.

It wasn’t a very well structured proposal and the chairs decided not to progress it. So it wasn’t presented. Instead we ran a kind of consultation, a community discussion about this topic, about Whois data quality.

And that will likely spawn a longer discussion between now and our next meeting in Bangladesh. So if anyone who is kind of interested in this topic for the APNIC region, I would encourage you to participate because you’re all stakeholders.

Thank you very much.

John Curran: Excellent. Folks, we are going to close the microphones pretty soon, so approach the mics.

Louie Lee: Hi, Louie Lee, Google Fiber. I’m looking at my last validation email. And I would like to suggest that right between your introductory paragraphs and where it says your POC information, add a link – why is validation important. And just point it to something that points out why it’s important just like you pointed out now.

Leslie Nobile: That’s good. Would you mind sending me a quick email to remind me of that because I have a bad memory?

Louie Lee: Okay, I’ll forward it. Lousewies?

Lousewies van der Laan: Hi, Lousewies van der Laan, ICANN Board. In the European Union there’s a huge discussion about Whois and privacy because some say that the current rules contradict our new data retention directive. And it’s very hard for operators to figure out where they stand. They’re kind of caught between a rock and a hard place.

I was just wondering whether you had the same discussion going on within this region and whether there are privacy violation concerns.

John Curran: So in general the Number Resources are assigned to organizations. There are very small organizations – single, doing business as, and et cetera. But we have a privacy policy that says that we do not provide information in the public Whois that goes all the way down to a street address for very good reason. And that’s because there’s norms and standards in many countries that prevent that level of information. So already when you provide that level of information it won’t be reflected in the public Whois.

And it’s because some people who are a small organization are also an individual and should be entitled to that. We actually worked a Whois privacy policy for residential addresses back in 2007 or 8.

Marc Lindsey: Marc Lindsey, Avenue4. I wanted to follow up on the comment about the policy impediments for legacy holders to come forth to ARIN in a variety of circumstances. I concur with John that you can frequently cheat and transfer as a legacy holder without going through the RSA process.

But the bigger problem I find in advising a lot of clients who are not necessarily transferring is that they look at the body and say, I’ve got an entity that no longer exists as a legal entity or I’ve acquired an entity. I go to ARIN and I want to reflect my current control issues, identify a new POC.

They say, great, you’re approved. Looks like it’s a great M&A. By the way, sign this contract. It gets elevated to the lawyers and they say, wait a minute, you’re changing the legal status. Whatever it happens to be, it’s murky. You’re changing my legal status and I’m giving something up.

And no in-house lawyer generally would give a thumbs-up for them signing that contract if they had a choice. So a lot of legacy holders who aren’t selling, they have a choice of not signing, and a lot of them won’t sign it. And the records will reflect being inaccurate.

And a lot of times, I’ve tried to advise clients to go back and get an ORG recovery, and even when you go through that process, if the POC is invalid, ORG recovery, ARIN will ask them to sign an RSA. So you have the situation where you have a legacy holder who has an M&A activity. They want to have an accurate database registry. They’ve got to go through a process of converting their rights just to help the community have a more accurate record.

Vint Cerf: I’d like to respond to that. I’m not sure what these legacy holders think they have. But they have only the right to use. They don’t have ownership. This is not property.

Marc Lindsey: I disagree.

Vint Cerf: Excuse me. It’s very important that it not be considered property.

Marc Lindsey: I disagree with you, but that’s irrelevant because the point is we have large companies who are choosing not to come to you to update the database and introducing these problems for everybody because they believe like I do and not like you. But we both could be wrong but that’s not the point.

The point is, the externality is people, companies, large companies are not coming to update the database because they perceive that they’re losing something. But that perception is legit or not, it’s a real fact that’s introducing why 55 percent of the legacy holders don’t have valid POCs. Not all of them are doing that, but I know a fair number of legitimate Fortune 500 companies saying, I’m not going to do it. It’s not worth it.

John Curran: To be clear, Marc. So to the extent that someone has a set of legal rights that aren’t reflected in the LRSA, on to the IP address blocks, if they have those rights and we’re not reflecting them, they can go to court and perfect those. Okay. We don’t interfere with that. And we cooperate with all court judgments in this area that are relevant.

So the fact that someone may believe they have rights. I understand it could be an impediment. But I can’t really do something about someone’s beliefs that aren’t actually enforceable.

Let me finish. So I want to be very clear. There are a lot of legacy holders who historically have not updated their contacts, allowed them to atrophy over time as a result.

Some of that happened well before ARIN existed. And we’re now in the situation where we’re actually seeing the reverse. You’ll see some stats coming up where the number of Number Resources under RSA, RSA or LRSA, is increasing and the number not under any agreement is decreasing because the market is bringing those to bear.

So if you’re doing a transfer, yes, if you’re doing a transfer and you’re doing a partial transfer, at the end of the day you’re going to have Number Resources and you wonder about the particular pedigree and the conditions under which you’ll hold your remainder, I can understand some concern. But generally people are transferring the entire Number Resource. And what they’re getting is their payment.

So in those cases they’re actually not very concerned about signing the RSA. We have legacy holders coming in and doing it all the time because they’re transferring them and they don’t care. The remnant language of the RSA doesn’t get in their way because they don’t hold Number Resources at that point.

So this problem is working itself out as is. What would be helpful is more education in the community about this.

Marc Lindsey: So I’m with you. So, yes, the money incents people to get the lawyers out of the way periodically. So oftentimes that will drive people to say I know you don’t like this. I know this RSA doesn’t look good to you, but we’re selling and you’re going to have to hold your nose and go forward. That happens. There are certain situations where the money is enough of an incentive.

But what I’m driving at is we do a lot of work that has nothing to do with transferring a money exchange situation. It’s trying to get those clients who got the POC validation request email. They’ve got records that reflect an entity that they still only control that no longer is a legal entity. They’ve got to go through a burden that is beneficial to everyone and that burden should be reduced. It should be reduced and shouldn’t be there because it’s in our mutual goal to have those companies update the registry to be reflective to minimize hijacking paths, to make the record, make the record more accurate.

So what I’m driving at is we can have this policy discussion about property, not property and the benefit of the RSA. But the real fact is legitimate companies with a lot of resource space are voluntarily choosing to keep the registry inaccurate because they don’t want to overcome what they perceive is to be a burden.

John Curran: Understood. And we recognize it’s an issue. But counterpart is that without having some – there’s some legal risk involved in recognizing a company that comes in and says I have this chain of documents that show that these resources are under my, should be under my control now.

When ARIN has to go through the process of actually doing that change, if you representing that customer says I need all this updated, you can see exactly why you don’t want to have your rights encumbered by signing an RSA. I understand that.

Hypothetically, if your customer isn’t the rights holder, okay, then someone else is potentially impacted when we follow that chain of documents and update the registry contrary, we update in favor of you and your client against someone who might actually be the rightful rights holder.

The RSA provides us important protections because we’re doing this at your behest.

Now, we are reviewing that but it’s very difficult for us to actually go through and change the organization – not a contact. We can update contacts all the time. But to change the organization assigned a resource without there being a legal agreement that provides indemnification, you’re actually asking ARIN to risk the entire registry for your client’s beliefs. Okay?

Marc Lindsey: I’m with you. And we’ll take the rest of the cocktail hour. But, the last point I’ll make on that. You have that RSA is how many pages now? 16 pages? 19 pages?

John Curran: Yeah.

Marc Lindsey: How much of that do you need to address that point in the context of M&A. I’d encourage you to focus on that, on the M&A transfers and not have the full 20 pages apply in that context.

John Curran: Excellent point. We are actually reviewing that same point. Okay, thank you, everyone. Any other questions for Leslie? I didn’t get a chance to say I’m closing the mics. But we are closing them. We have one more.

Kevin Blumberg: Kevin Blumberg. There are a number of organizations – banks, financial institutions – that offer what I would consider a gold standard when it comes to locking down your data.

CIRA, which is a very similar kind of registry for domain names but not IP numbers, offers that level of service when it comes to locking down your assets. Is ARIN planning to do something similar.

John Curran: You mean locking down a resource in dispute?

Kevin Blumberg: No, locking down the resources – my organization has a bunch of resources. I want to know that they’re locked down and protected so I don’t have to worry about what was just brought up here which is the threat of even if my POC is validated, somebody takes over my email account, whatever. I want it locked down off line in such a way that no transfers occur on my records.

John Curran: We do not offer that presently. That’s an excellent suggestion.

Paul Andersen: For the new Services Working Group.

John Curran: Thank you, Leslie.

(Applause.)

Closing Announcements & Adjournment

John Curran: Okay. All of this enthusiasm may have caused me to not let you out at 4:00. I’m actually going to defer the Software Development Update because if we do that you won’t see the beach, and instead we’re going to move directly to the close. First thanks for our network sponsors and webcast sponsors, C&W Business and Google.

(Applause.)

Okay. We have a social tonight. There’s a beach barbecue at Sunrise Beach. You can get there. You can walk. There’s golf carts. Wear a name tag. It’s in there. And it’s at the beach. Wonderful place for a social.

The thing I was going to point out is that there are arrangements for rain. There’s a pavilion there. But we can’t control things. We’re set out on the beach now and we’ll make do if it turns out to rain. Right now we’re still good so I recommend people get out there while the weather is good.

Shuttle schedule. We have revised the schedule. There’s now two shuttles running the hotel route on 13-minute intervals. So they’ll be running basically Monday 7:45 in the morning to 8:00 AM. They run 4 to 5. They run 6 to 7, 8:30 to 10. Tuesday they’ll be running in the morning and in the afternoon.

The normal hotel shuttle is also running. We have abundant shuttles. Reminders. Breakfast tomorrow 8:00 AM to 9. We’ll resume with the Public Policy session first thing at 9:00 AM. That’s it. Welcome everyone. I’ll see you at the barbecue tonight on the beach. Thank you.

(Meeting recessed at 4:13 PM.)

Network Sponsor

Webcast Sponsor