ARIN 43 Public Policy Meeting, Day 1 Transcript - Monday, 8 April 2019 [Archived]

Please 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. If additional clarification and details are required, videos from our original webcast are available on our YouTube channel.

For an executive summary of this day of the meeting, read the daily digest on the TeamARIN website.

Public Policy Meeting, Day 1 - Opening Announcements

John Curran: Good morning. If folks will come in and be seated, we’ll get started.

Welcome, everyone, to lovely Barbados. I’m John Curran, President and CEO of the American Registry for Internet Numbers. I’d like to welcome you to ARIN 43.

Here we go. So I’d like to say we have a very busy meeting, and we have quite a few folks here to help participate in the discussions. And I’d like to say that our Board of Trustees is here. So that’s Dan Alexander, Paul Andersen, Nancy Carter, myself, Regenie Fräser, Patrick Gilmore, Peter Harrison and Bill Sandiford. We have our Chair, Paul Andersen, our Vice Chair, Bill Sandiford, up here at the table.

Our Advisory Council is here. There’s 15 of them. I won’t read the names. AC members, please raise your hand. That’s the ARIN Advisory Council, and they work on shepherding the policy process. When you folks propose ideas, the ARIN AC is responsible for taking control of those, moderating the discussion on the list, updating the proposal and coming up with fine ideas for us to discuss here in this room.

The Chair, Tina Morris, is here, at the head table. And Leif Sawyer, the Vice Chair, is also at the head table.

We have a number of folks from the NRO Number Council – Kevin Blumberg, Louie Lee and Jason – well, Jason isn’t here. But Kevin and Louie are here.

The NRO Number Council is the organization that works on global policy. They get together with the other representatives from the other four RIRs, and together they work out the global policies used to administer the central pools at the IANA. The central pool of IPv4, IPv6 and ASNs are administered by the policies those folks work.

Those policies are actually developed here and harmonized by this group until they’re consistent in all five regions, then they’re ratified and used. Haven’t had a global policy in quite some time, which you might say is a good thing.

Our RIR colleagues. The RIR system has five RIRs. We have folks from AFRINIC, APNIC, LACNIC and RIPE here, making sure that they can bring back to their communities what’s going on in ARIN because, while we all have our own portion of the registry, it is one total global registry. And so to that extent, we need to coordinate.

We have our ARIN leadership team here. This is the senior management team of ARIN: Myself; Richard Jimmerson, our COO – Richard, where are you hiding? – Anne-Rachel, who handles our government affairs; Erin, who handles our HR and admin.

Susan Hamlin here in the front row – Susan is the one who makes this meeting work, her and her team – Senior Director, Communications and Member Services.

Mark Kosters, who runs our engineering; Leslie Nobile, who handles global registry knowledge, tracking what’s happening across the integrity of the whole registry; John Sweeting, the man who runs the registration services, probably the department most of you interact with; Val, who handles our financial services, hopefully the department you don’t have to interact with much because everything is smooth; Michael Abejuela, our Associate General Counsel; and Bevil Wooding, our Caribbean Outreach Liaison.

We also have Steve Ryan, our General Counsel, here in the back. Very good.

We have our ARIN Fellowship Program, and the Fellowship Program provides for people to come to ARIN and be able to learn what we’re doing here and bring it back to their communities.

This year we have three Fellows from Canada. You can find them because their badges prominently have a Fellowship. So you have Jaymon Lefebvre, Imran Mohiuddin and Matthew Wilder, are our three fellows, and they have mentors from the AC.

And the Caribbean – we have a lot of Caribbean Fellows. That’s wonderful. So Suzette Burley, Rudolph Daniel, Krislin Goulbourne-Harry, Richard Hamilton and Cathrona Samuel. If I’ve maimed your name, I’m sorry; find me at the break, and I’ll get it right on the future slides.

And US, we have four Fellows from the US area – Jeffrey Anderson, Mike Arbrouet, Frank Hoonhout and Barry Sherwood. These folks are here. They’re attending and learning about our policies and processes, and then they’re going back to their communities so people understand in their communities in their part of the world what we do here at ARIN.

So all of our newcomers attended an orientation yesterday. They get to meet the staff, our representatives from AC and Board, and they learned about ARIN.

So we have them fill out a survey that talks about what went well, what doesn’t go well, what additional information we could add to the newcomer orientation.

At this time I’m going to do a drawing of those surveys to give out a gift certificate. We like to encourage participation. I need someone from the audience, second row, third one. Owen, come on up.

(Laughter.)

It does appear random. You sit in different places.

(Laughter.)

Thank you for filling out these surveys. They’re very helpful to us.

And the newcomer who filled out this survey Michael Casadevall. You’ll get a certificate – you don’t need to come up; we’ll email you a gift certificate for $100 from ThinkGeek. Thank you for filling out the survey.

We have remote participants as always. The remote participants have a webcast of this going on in the back. They have a live transcript of what we say, which is a good reminder that we need to be polite to the transcription people and talk at something other than my normal Boston pace.

So when you’re speaking, speak clearly, slowly if you can, because we want to make sure we have a good transcript. The remote participants often rely on that.

We have downloadable meeting materials. They’re on the website. They’re also in your app. If you have the app on your phone, you can click, all get the meeting materials.

The virtual microphone and consensus polling via Slack. People who are remote participants, they have the ability to, when they have a question, ask that online. It will be read at the mic. And when we do a poll of consensus, a show of support, someone can add themselves to that even though they’re remote. So you have full participation remotely.

Attendance stats. We have 63 attendees from the US, eight from Canada, 34 remote participants, 31 from the Caribbean and 15 from outside the region.

Emergency procedures. Well, if there’s an emergency, go to the beach. Head out the exit, find a nice spot. Shouldn’t have to worry much about that.

Download the meeting app. I mentioned this. We have a meeting app. It’s useful. You can see the map of the hotel, where the rooms are. You can see all the sessions. You can find out the speakers. You can find out the attendee list. It’s all available. Feel free to click on this link to get it.

I’d like to thank our sponsors. Two of our sponsors, our Network Sponsor, which makes sure we have connectivity and our webcast, very important, C&W Business and Google. Let’s have a round of applause for our sponsors.

(Applause.)

Additionally, we have meeting sponsors that make these meetings possible because there’s quite a few expenses and we don’t charge people for people who preregister for the meeting. So our Platinum Sponsor, Addrex, and our Silver Sponsor, IPv4Mall. Let’s have a round of applause.

(Applause.)

Okay. So a couple of things, the discussions of the policies. The Board of Trustees Chair will moderate them, and they’ll make sure – he’ll make sure everyone can speak, has a chance to be heard. This means that please go up to the microphone and state your name, affiliation, be clear about it.

There’s rules in your Discussion Guide if you have a printed copy. Or you can go online or it’s in, again, the online app. The guide says be polite, focus on the policy, not on the speaker.

Please speak once on a Draft Policy. Give other people a chance to speak before you approach the mic a second time.

You’ll find all the guides online. So we have a pretty full agenda today. Our agenda is we’re going to have our sponsor, C&W, come up, Jenson Sylvester. That will be wonderful.

We have a Regional Policy Update where we talk about what’s happening in the five RIRs for address policy. We have our AC Docket Report. The AC will talk about the draft policies and proposals that they have to work on and what they’re doing with them.

We have a Policy Implementation and Experience Report, which is where we report back to the community issues we see with policy – how policies have been adopted in the past are being implemented, any issues we might have.

We have the Internet Number Status Report, reporting on the free pools maintained at IANA and the issuance out and how the RIRs are all doing with their issuance of number resources.

We have a report from the IETF, from our IETF Reporter. IETF is the place that makes the protocol standards, changes the protocol standards, adds new protocols. It’s always interesting to look over the horizon see what’s coming at us.

RDP, we have a consideration of two Recommended Draft Policies. Either of these could be sent to the Board for ratification after this meeting.

The first one will be 2018-2: Clarification to Initial ISP Allocation. The second one will be 2017-12: POC Notification and Validation Upon Reassignment or Reallocation.

In the afternoon we have consideration of Recommended Draft Policy 2018-5: Disallow Third-Party Organization Record Creation.

We have consideration of a number of draft policies that aren’t recommended, which means they won’t be sent to the Board necessarily for adoption after this meeting, but could be recommended at a future time, and they’ll come back to this community for consideration. So that’s ARIN-2018-6: Clarify Reassignment Requirements in 4.2.3.7.1.

And we’ll have a report of our website and routing registry update. We’ll have consideration of Draft Policy 2019-1 on IPv4 Request Requirements. We’ll have a Draft Policy update on – for 2019-3, which is an Update on the IPv6 Deployment Block.

And we’ll have a presentation from a study that was done on economic factors affecting IPv6 deployment. Should be an interesting discussion.

We have then a presentation talking about future meeting agendas. So right now ARIN staff sets the meeting agendas, and we’d like to talk to you a little bit how that’s done maybe how you can help.

And then we’ll close for the day, and that will be our – quite a Monday. We’ll be pretty busy today.

So there’s a room out the doors and around the corner called Garrison 1. That’s a policy discussion room. If you want to grab someone and talk about an idea and maybe make it into a draft proposal or you want to follow up with a member of the AC, grab them, we have a room set aside where you can discuss things like that.

Help desk. Registration Services Department has a help desk. It’s right outside the door. It will be available for ARIN 43 and at CaribNOG which follows. The hours are 8 AM to 5 PM each day. If you have an open issue, if you have something you’re trying to do with ARIN, a registration request that maybe is stuck or a ticket that’s not moving, come over and see the registration desk.

Women’s Networking Reception tonight, 5 to 6 PM at Needhams Ballroom 3.

We have a social tonight at Copacabana. Your social badge or regular badge will get you in. We have shuttles running at 6:45, 7:00 and 7:15, and they start returning at 8:30. This is a short bus ride away for an authentic Barbados experience. Should be a wonderful time.

Okay. After ARIN 43 this week we have CaribNOG meeting. And it will meet Wednesday through Friday. And we have – ARIN CTU has a Public Policy group meeting taking place on Thursday.

So at the head table, I already introduced all these folks so I don’t need to do it again. Thank you. So we’ll move right ahead into the meeting.

First one up is going to be we’re going to bring our sponsor presentation. No presentation? Very nice. Okay. Jenson Sylvester, come on up.

Jenson is our sponsor of this meeting, C&W. I don’t have a bio? I know your bio. Come on up. Jenson has been involved for 15 years in telecommunications at C&W in this region. We’re very happy to have C&W as a sponsor for the meeting, and I’ll turn it over to you.

Sponsor Presentation

Jenson Sylvester: Thank you very much. Thank you, John. Business partners, industry friends, ladies and gentlemen, good morning.

All: Good morning.

Jenson Sylvester: Welcome to Barbados. It gives me great pleasure to join you today as Barbados’ leading telecommunications provider reaffirms its working relationship with ARIN.

This location is a doubly special moment for both ARIN and Cable and Wireless as together we were able to create history last month, with the first-ever commercial deployment of IPv6.

(Applause.)

I’d like to thank our local team headed by Shawn Holder for all the hard work and effort in pulling this off. It’s a true testament to the strength of our collaboration in further accelerating the potential of individuals, organizations and our wider Caribbean community.

As you know, Cable and Wireless has been providing the people of Barbados with reliable connections for more than a century now. And as we look to the future, we are pleased to say that we are now on the cusp of offering the facility of IPv6 to our entire B2B customer base.

Over the years, we’ve been laying the foundation for the fully connected environment which we all now enjoy.

At the same time, we continue to invest in our networks and people. And we will also continue to place our focus on innovation to the benefit of all Barbadians who every day display great aptitude in leveraging technology for future development and growth.

Of course, like ARIN, we do this in the belief that our ability to positively influence society feeds directly into our own success as an organization.

This is why we tip our hats off to you for structuring ARIN as a service-oriented organization that is responsive to the needs of the public and is totally driven by a community of end users.

Likewise, we are also very proud of our relationship with the local business community, in particular, the local education, hospitality and financial sectors.

And we stand ready to work with all stakeholders to see that their respective projects become a reality in the shortest possible timeframe.

As Barbados’ leading telecommunications provider, we are a company comprised of history makers and future enablers. And we are acutely aware that connectivity and the access to reliable connections has become the glue that binds us all and brings us closer together.

So to the folks at ARIN and our other industry partners, we say thank you for providing us with a platform that connects us all to the future.

Please enjoy your time in Barbados, and we certainly look forward to our sustained collaboration in the coming days and beyond. Thank you.

(Applause.)

John Curran: Next up I’ll have Richard Jimmerson come up and give our Regional Policy Update.

Regional Policy Update

Richard Jimmerson: Good morning, everyone. One of the standing agenda items that we have at each public policy meeting, right at the beginning, at requests year over year, is a brief description of what we have in regard to policy discussions in the other regions.

So this discussion that we’re having in the room here today happens all over the planet throughout the year, also in the AFRINIC region, APNIC, LACNIC and RIPE NCC regions.

Now, there’s a slide at the end of this presentation, if you want to go to their sites where all these policies are described for more information, you can do that. But in the AFRINIC region right now, they’re talking about making multi-homing not required for AS numbers, clarification on temporary resource usage, Internet number resource review by AFRINIC and an abuse contact policy update.

Also, they’re talking about clarification on IPv6 sub-assignments, inter-RIR resource transfers that a lot of us use today inside the ARIN, RIPE and APNIC regions; Soft Landing Update for their last block of IPv4 address space; and AFRINIC Policy Development Process in general changes, changes to that.

In the APNIC region, they’re talking a bit to that validation of the abuse mailbox and other incident response team emails. That’s consensus at their last meeting.

They did not reach a consensus in the last meeting about clarification on IPv6 sub-assignments or the Policy Development Process update. A new proposal on modification of transfer policies is up in that region.

In LACNIC they’re talking about mergers and acquisitions all the way throughout for AS numbers, IPv6 and IPv4. And, in addition, they’re talking about IPv4 resource transfer policies comprehensively, in general, and the inter-RIR transfer policy. So they’re looking to join the three existing regions with inter-RIR transfers – Acceptable Use Policy for the policy list, too, where there’s communications going on there between members of the community.

RIPE NCC’s talking a bit about Internet Routing Registry database nonauthoritative route object cleanup, clarification of definition of assigned provider allocated addresses, reducing IPv4 allocations to a /24 and BGP hijacking as a RIPE policy violation.

If you want to look at any of these in detail, to set context for some of the discussions that we may be having here inside this region, you can do that, and you can find that information easily at their websites listed here. Thank you very much.

John Curran: Any questions for Richard?

(No response.)

Thank you.

(Applause.)

Next up, Tina Morris, the AC Chair, to give the On Docket Report.

Advisory Council Docket Report

Tina Morris: Good morning. The AC has an incredibly busy docket right now. We have three policies in Recommended Draft state. That means after this meeting they could be sent to the Board for – I’m sorry, sent to the community for Last Call and then adopted by the Board – sent to the Board for adoption.

We have eight Draft Policies under discussion right now. These are policies that we’re still working on the language. We’re still looking to see if there’s community support. We’re still just working on them in general. We have one editorial change and one proposal that has not yet made it to draft status because the shepherds are still working with the author.

Recommended Draft Policy 2017-12 was actually remanded last July for the AC to look at because the impact was considered extreme. Since then we’ve redone the language a bit and it’s in new format. It requires ARIN to identify and contact organizations related to points of contact before they’re put into the database.

2018-2: Clarification of ISP Initial Allocation is meant to change how the block sizes and the language of the initial allocations are presented in the NRPM to clarify.

2018-5: Disallow Third-party Organization Record Creation. It’s meant to address Whois entries that are not authorized by the recipient of the addresses.

2018-6: Clarify Reassignment Requirements in 4.2.3.7.1 specifies that not only a customer – that only a customer’s name is required for assignments, also just to clarify policy, make sure everybody understands simplify NRPM.

Draft Policy ARIN-2019-1: Clarify Section 4 IPv4 Request Requirements, unmet language, application to v4 space only, and that they can’t have recently transferred address space to another party.

2019-2: Waiting List Block Size Restriction, it addresses the unmet request limit. Currently there is no limit. It reduces it to a 22 or smaller. Currently the waitlist is suspended. This is one of the policies meant to address that suspension in the fraud issues that have been in play.

2019-3: IPv6 Deployment Block, adjusts the allocation language concerning the dedicated v4 block to facilitate v6 deployment, changing the minimum to a 24 and limiting the total to a 21.

2019-4: Allow Inter-regional IPv6 Resource Transfers. Currently v6 is restricted. It cannot be transferred to another region. This would change that.

2019-6: Longer Hold Time Requirements for 4.1.8 Recipients. This is another one meant to address the issues with the waitlist, changing the wait time from receiving the space from 12 to 24 months.

2019-7: Elimination of the Waitlist is yet another one, trying to address the waitlist issues. This removes the waitlist for IPv4 requests entirely and replaces it with an auction procedure administered by ARIN. That one should be interesting.

2019-1 is an editorial change. We won’t be discussing it at the meeting. But it is in Last Call to the community. And it’s open for input until April 25.

These are not on the agenda, along with the current proposal that hasn’t made it to draft state.

Draft Policy 2019-5, we’re still working on the language. It’s not quite ready to be presented to the community; it will be presented in October, and it will be on the PPML.

2019-1 is an editorial change which we don’t generally present. Thank you.

John Curran: Any questions for Tina?

(No response.)

(Applause.)

Thank you. Next I’ll have John Sweeting come up and give the Policy Experience Report.

Policy Implementation and Experience Report

John Sweeting: Thank you. Good morning, everyone. I’m John Sweeting. I’m Senior Director of Registration Services. I’ll talk about a few issues concerning policy, current policy that my staff finds to be either vague or contradictory to what we think that the community is really trying to achieve with those policies.

So, as you see here, policies that aren’t working as expected. We do this based on customer feedback that we receive daily at the RSD help desk through calls, tickets, emails.

And it’s also we also have some ideas for new policies that come in every once in a while, which we just feed over to the Advisory Council.

For the ones that I’m going to talk about today, the community, you’re the ones that actually have to decide what we need to do with them, how we need to change them or not change them, depending on what you feel you really want those policies to achieve.

So the policies I’m going to review today are 4.10: Dedicated IPv4 Block to Facilitate IPv6 Deployment, as well as 4.5: The Multiple Discrete Networks; and also 6.5.8.1, your IPv6 Initial Assignment Criteria.

Okay, so 4.10 is the dedicated IPv4 block that we have set aside to facilitate IPv6 deployment. It reads in part: “In order to receive an allocation or assignment under this policy, the applicant may not have received resources under this policy in the preceding six months.” Another tidbit is you can only receive a /24 at a time. You can only qualify for a /24.

Six months later, if you’re using 80 percent of that block for the purpose of IPv6 – to assist in IPv6 deployment, you can apply and receive and be approved for an additional /24. That can happen every six months.

Under Multiple Discrete Networks: “Upon verification that the organization has shown evidence of deployment of the new discrete network site, the new network, or -works, shall be allocated the minimum allocation size under Section 4.2.1.5.”

So the problem that we have here is if you are a multiple discrete network and you come in and get a /24 for a site to transition – to help with your transition to v6, if you have another multiple discrete site that you’re deploying v6 at, you cannot receive – under current policy, you cannot receive another /24 to help deploy v6 at that site unless you wait six months.

This is becoming more – we’ve had more questions about that. Even though we haven’t actually encountered an MDN request for 4.10 space, it’s because we’ve been asked the question, told that – and the answer has been that they can’t apply for it.

So my staff brought it to me, and I said that doesn’t sound right; that doesn’t sound like the intent of the community would be to not – if somebody has a multiple discrete network that’s been recognized and they have a need at those different multiple discrete networks to have a /24 for the deployment of v6, we’ve recognized it as multiple discrete networks, we’ve recognized they may be announced as different upstreams. It just didn’t seem like it jibed with me that that’s really what the community would want and that’s how they would want us to treat that.

So the questions that we have for you, the community, is should each autonomous network be reviewed separately under multiple discrete networks? Does the 4.10 six-month requirement apply to the organization as a whole, or should we apply it to multiple discrete networks, the networks within the organization rather than the organization as a whole?

Today, absent community input on this, we’re interpreting it to mean that we can only allow one /24 per six month per MDN to the organization.

As I said, that’s not exactly what the policy states today, but that’s how we’re interpreting it. And we really would like feedback to make sure that we are enforcing that policy as the community wishes it to be enforced. Our thinking is that we really – we don’t want to stand in the way of IPv6 deployment. So if somebody has a need and we’ve already recognized they have that need for the multiple discrete networks, that we should allow them the block at each of those sites, the /24 at each of those sites to help them deploy.

Cathy has a question already. I haven’t even called for questions. Go ahead, Cathy.

Cathy Aronson: I can wait if you – I’m Cathy Aronson. If they have two different Org IDs, can they get two different blocks under that policy?

John Sweeting: Yes, absolutely.

Cathy Aronson: I would be under the opinion that if they have MDNs, they should be able to, too, but anyway, thanks.

John Sweeting: Thank you.

Chris.

Chris Woodfield: Chris Woodfield, Salesforce, ARIN AC. The multiple discrete networks, I have a history because I worked for the company that got that into – that worked to get that into the policy.

The target, the target of that policy language was intended for organizations that run effectively BGP islands – so that I have AS number one over here, AS two over here – are completely separate. They can be treated as separate entities for the purpose of qualifying for v4 space.

Just to add some background to that. So my impression is that, given the ambiguity, you’re following the correct policy.

John Sweeting: Okay. Thanks, Chris.

Kevin.

Kevin Blumberg: Kevin Blumberg, The Wire. To me, these are two separate policies and co-mingling them actually affects one of the inputs related to 4.10, which is that we’re giving out last little bits to organizations that need a kick-start with v6.

Without having statistics on the number of Orgs with MDNs and the number of MDNs that they have under their portfolio, it seems like one Org could use this as a way to jump-start their entire network with v4 using v6, which is great, but deplete this pool significantly.

I don’t know what the largest number of MDN sites under one Org is, but if each one is treated separately it’s a fairness issue. For me 4.10 was meant to be for – not for small organizations but for an organization to get a kick-start for v6 by getting v4.

We’re giving now a thousand, if you had – I don’t know if there’s an MDN with a thousand /64, /128, whatever it may be, times that.

That doesn’t seem quite right. I would expect that 4.10 should be an isolated policy and not pulling in things like MDN.

John Sweeting: You’re stating just per organization. So we just make them get Org IDs for each one of their discrete sites rather than keep it simple?

Kevin Blumberg: I think there’s a complexity with MDN that shouldn’t be intertwined into. Like I said, without some real statistics on this, I’d rather see 4.10 left stand-alone and not apply things like MDN into 4.10 which would effectively mean one Org ID would be allowed to get the space from there.

John Sweeting: And we do have statistics on the size of the 4.10 pool.

Kevin Blumberg: Not the 4.10 pool. The MDN. How many Orgs have MDNs and the number of MDNs that they have.

John Sweeting: Okay, we can get that.

Kevin Blumberg: Thank you.

John Sweeting: Back mic. I’m sorry. It’s just hard to see. The sun is bright here.

Michael Casadevall: Michael Casadevall, NARALO. Do we have current statistics on what is currently available in the 4.10 pool and projections towards exhaustion since that, I think, would influence the policy decisions?

John Sweeting: Yeah, I’m going to give that in the RSD department update. I believe it’s somewhere around 98 percent of that pool is still available.

Michael Casadevall: All right, thank you.

Owen DeLong: Owen DeLong, ARIN Advisory Council. 98 percent could go away very quickly if we start issuing additional /24s for MDNs and people decide to use that liberally. I’ll avoid the word “abuse” for now.

I personally think that expanded 4.10 to MDN might not be such a bad thing if we use the Policy Proposal that is currently on the docket regarding 4.10. One of the side effects is capping the total amount issued to any one Org at a /21. And I think once that safeguard is put in place, it’s probably not so bad to allow Orgs with MDNs to get multiple /24s based on their MDNs up to a total of a /21.

I think allowing any Org more than the /21 out of 4.10 is completely contrary to the intent of 4.10, even if they have a thousand MDN sites. I really wouldn’t want to see that happen.

John Sweeting: Yeah, just realize, as Cathy brought up, that these organizations could – instead of doing it under multiple discrete networks, they could just have a separate organization registered with a separate Org ID and get those ASes for those sites under that Org ID and qualify.

So just keep that in mind because I think Cathy kind of hit the nail right on the head with that comment. Andrew.

Andrew Dul: Andrew Dul, multiple discrete network guy and ARIN AC. My thoughts about this are when we did 4.10 originally, I don’t think we considered this as an intertwinement and we wanted 4.10 to stand on its own. So my interpretation of 4.10 is that it should stand on its own today.

And I would encourage people who would like to apply MDN-type methodologies to 4.10 to make a comment on the existing Draft Policy that I authored to update 4.10 based on information that John brought to us, John Sweeting brought to us in the AC in January in face-to-face meetings.

So please make comments on the Mailing List for the draft that’s outstanding right now. And if you feel strongly about this, we can include this in that draft update.

I don’t have that policy number off the top of my head. But it is one of the drafts that we will be discussing today and tomorrow.

John Sweeting: Thank you, Andrew. And just a little bit – go ahead, John, you go first – I was just going to say the three queries we’ve had into this have been from organizations that had two multiple discrete networks.

John Curran: Any other questions for Mr. Sweeting? Thank you, John. Round of applause for this one.

(Applause.)

He’s not going anywhere because now he’s going to give the Internet Number Status Report.

John Sweeting: I actually have another policy – the questions – so this is on initial assignment criteria for IPv6. Organizations may justify an initial assignment by having a previously justified IPv4 end user assignment from ARIN or one of its predecessor registries. The problem we’re having with this is that this policy was written prior to depletion.

It doesn’t really tell us how to interpret it in the case where an organization cannot qualify due to the depletion – not that they can’t qualify – well, they can’t qualify for the IPv6 but they can qualify for IPv4, but they can’t get IPv4 because they have to go on the waitlist.

So the questions for the community is can the current practice – is the current practice correct? If so, it might be wise to formalize it in a policy. If not, then guidance should be provided.

And what we’re doing today is that if they qualify for v4 and they’re on the waitlist or they’re waiting for a transfer, then we say they qualify for v6.

In other words, we can go with status quo. Qualifying for IPv4 qualifies you for IPv6 or other options. And if that is correct, then possibly it should get updated in policy to reflect that it’s not just that they have v4 but that they qualify for v4.

Owen.

Owen DeLong: Qualifying for v4 was one of many criteria by which you can qualify for v6. So – or having v4, rather, was one of multiple criteria by which you can qualify for v6.

I think the other criteria by which you can qualify for v6 are perfectly adequate and that I’m fine with the staff interpreting qualifying for v4 qualifies you for v6 because I agree that circumstances now were not envisioned at the time of writing of the v6 policy. I had some hand in writing the v6 policy. So I will admit that.

But I do think that the other criteria are adequate to cover most initial circumstances where an organization doesn’t have v4 or isn’t getting v4.

So I’m not sure policy work is really necessary here.

John Sweeting: So, you’re saying just the status quo on continuing marching where we’re marching? Fine.

Thank you. Any other questions? If not, as John said, I’m going to stay right here and go into the Number Resource statistics overview. There you go. Thank you, Kerry. I’ll give the Internet Number Resource Status Report.

Internet Number Resource Status Report

John Sweeting: So this is just a representation of the distribution of the 256 /8s from IANA. Also, if you remember right, some of you will remember at our last meeting, it was requested that we give a representation of where all the space is today because it’s due to transfers and everything.

We don’t have that slide yet. That slide will be in the next presentation that’s generated by the NRO. So at our fall meeting I will have a slide that speaks to that.

This is a representation of the total IPv4 addresses that are managed by each of the RIRs. As you can see, ARIN is way up there, but a lot of that is due to the legacy. Half of our space is legacy space as just about everyone is aware of.

So that’s why that, the 99.8, whatever that is, thousand, million, anyway.

Available IPv4 space in each RIR. This is space that’s available for them to be given out. You have your last /8 policies in place at RIPE and APNIC and LACNIC. AFRINIC and LACNIC actually still have a little bit of space left. They haven’t hit depletion, but they’re into some of their special policies that cover those last portions of IPv4 space that they have available.

So in terms of /8, this is just a historical representation of the space that each RIR has issued per year going back 10 years. As you can see, it’s gotten down to where it barely shows up.

IPv4 transfers. This does not include your merger and acquisition transfers. Number of transfers per year. Of course, it’s going up and up and up.

The number of addresses transferred by year, it goes up and down. The number of transfers keeps going up, but the number of addresses fluctuates. Some years we have some really big deals where one or two /8s change hands through transfers and other years we don’t have those big deals.

And those /8 transfers actually cause a big spike in, of course, the number of addresses that are transferred via the transfer – the M&As.

So the inter-RIR IPv4 transfers. This is representative of the number of transfers. What’s more interesting to everyone I’m sure is the total number of IPv4 addresses transferred between the RIRs.

As you can see, ARIN and our legacy pool, which a lot of people refer to as the free pool for the transfer market – although it’s not a free pool – but it’s the transfer market pool that has replaced the available addresses. So available addresses for the transfer market really come from that pool of legacy space, which ARIN is by far the largest holder of legacy space.

So you can see we have sent 16.6 million IPs to APNIC and received back 118,000. We’ve shipped off 8.8 million to RIPE and got back 299,000. And then you see between APNIC and RIPE it’s pretty even. They pretty much go back and forth with each other, 1.9 million from APNIC to RIPE and 1.4 million from RIPE to APNIC.

Moving on to the IPv6 statistics. This is a representation of what has been allocated to the RIRs from IANA. There was some early space that was given out that I believe is broken down in that last yellow ring. You’ve got an IETF reserve in there. You’ve got a 6to4 /16 in there, allocated to RIRs before they went to the /12 as being the size that they give to each of the RIRs. And then up in that little box you see each of the /12s that have been given out to each RIR.

As of today, no RIR has gone back for an additional /12. RIPE is very close to doing that. But they had some other things they needed to do before they actually went in and requested that and it was due – I don’t know if anybody’s paid attention to some of the Mailing Lists in IANA, there was a small block, I believe a /23, that was stuck at IANA that was reserved for RIPE, and actually RIPE had it reserved for one of their larger customers. But it was tough for IANA to get that to RIPE because there wasn’t a policy in place, a global policy anymore that allowed them to do anything but /12s to the RIRs.

So they got together. They came to the NRO NC, who conferred with the RSCG, which is the Registration Services Coordination Group. We all looked at it and decided that the best thing to do would be to take that /23 and do what was intended back prior to the /12 policy being passed, and they issued that to RIPE.

RIPE could not go and get that /12 prior to that because they wouldn’t have been able to qualify for anything for IANA; it would just make things more difficult.

So I would suspect that they will be going in for the first additional /12 sometime this year, and we’re not too far behind that.

This is IPv6 allocations issued by RIRs. As you can see, APNIC has been allocating the most with LACNIC. LACNIC is – they’re interesting there because I believe it’s like 90-plus percent of their members have IPv6. But there should be nothing too questionable about this.

Total allocated IPv6 space per RIR, which RIPE’s leading there. APNIC has the 75 million – 75,000 /32s. ARIN, LACNIC and APNIC, so even though LACNIC has a big high percentage of their membership, it’s not that much space. It’s not as much space as the other RIRs, I should say.

This is per year. The prefixes that each RIR assigns per years. So, rather than allocation and assignments. And this is the total size of IPv6 space in /48s that each RIR has assigned.

So you saw for the allocations we reported it in /32s because that is the primary unit that is issued, allocated. And in the assignments we report it in /48s because that’s the most prevalent and most policies refer to that.

Percentages of – here you go, here’s the percentages of members with IPv6 in each RIR. The pinstripes there, the top part of the numbers are members with IPv6 only.

One thing to remember on that is just because we show they have IPv6 only from ARIN doesn’t mean they only have IPv6 and they don’t have IPv4. They could have IPv4 that was assigned or allocated to them from their upstream but then they came to ARIN to get their IPv6.

So it’s hard to tell. We couldn’t really tell you definitively if there’s anybody out there that only has IPv6 and is only building their network and deploying their network with IPv6.

Nobody has claimed that as of today, so I’m not sure if there is any cases of that. But from ARIN itself, directly from ARIN we have 9.6 percent of our members have IPv6 only.

Moving on to the AS numbers. This is a chart of all AS numbers with the 16-bit numbers broken out there in the circle on the side.

I don’t think there’s a whole lot really interesting things to talk about there. Unless somebody has questions, then I’ll answer them when I finish with this, and you can ask your question.

How many ASNs has each RIR issued per year? It’s pretty steady. And it doesn’t seem to be going down. It hasn’t gone up much, as you can see. Like I said, it’s pretty steady.

ARIN, of course, gives out more 16-bit than most of the other ones only because we have the larger pool of them. Again, it’s back to the legacy stuff from the early years and all that.

Total ASNs assigned by each RIR. You can see ARIN there in the middle in the Syracuse orange. Or you could say Virginia orange, I guess – okay, Susan. I’ll plug you. Virginia’s playing tonight for the national championship. So everybody root for Virginia, unless you’re from Texas.

And these are the references. These stats, this presentation is posted to the NRO site. And that’s it. Any questions on that?

(No response.)

If not, then I will depart the stage, I think.

John Curran: Any questions for Mr. Sweeting?

(No response.)

Thank you, John.

(Applause.)

At this time I’d like to have Cathy Aronson come up and give the IETF Report. Pleased to say Cathy is our IETF reporter, and she goes traveling the globe and I guess entertaining herself in IETF meetings with all sorts of interesting characters in order to bring you this report. So, thank you, Cathy.

IETF Report

Cathy Aronson: Hi, everybody. I tried this time to – oh, God, that’s like an inquisition light or something.

(Laughter.)

I tried this time to actually have photos from the IETF and not from my backyard and stuff.

This is actually from Prague, which is a wonderful place, if you haven’t been.

So this presentation covers two IETFs. There was one in November in Bangkok and one a week ago in Prague. So if you’re looking something up, just keep in mind that it might be – it’s all intermixed. So it might be from a different IETF. And if you have any problems, just let me know and I’ll be happy to steer you to whichever one, because it’s all sort of melded together.

Let’s see. So a highlight. I found out sort of serendipitously that .horse exists. Did you know that? Anyway, if you Google – I mean you traceroute to bad.horse sometime when you need to be entertained, it’s pretty awesome and really funny. Someone clearly had way too much time on their hands out there on the Internet.

The other thing I never talk about in these talks is there’s this thing called PechaKucha that started at the IETF a few years ago. And they’re really entertaining little presentations. They’re sort of like bad attitude lightning talks.

And I wanted to just send you a pointer to those because if you need a laugh and you wanted to see IETFers making fun of IETFers, it’s a really good time. And it happens really late at night, and I’m usually too jet-lagged to go, but I watch them online. Those are highlights.

Okay, so I started this a while ago because the Chair of v6ops has challenged us to read a draft a week before the IETF. So I read a lot of drafts. And I don’t talk about most of them. But a couple of them, this one pertains to this – God, that’s a little puffy – this one pertains to this group. It’s all about sort of a survey of a prefix length given to end sites.

And the IETF has recognized that it’s this community that really makes the decisions about prefix length and who can qualify for what. But they also wanted to put together some information about the percentages of different areas that use different prefixes.

And I’m going to talk some more about this later, but apparently we have enough v6 for 102,400 years, which I think that that math is probably a little bit suspect. But it’s an interesting quote from the draft there, Maths Show, which is a good thing. Anyway, that’s a good draft to read.

I read the SIP specification again. I read it about a million years ago. But they just republished it as historic. And it’s really one of the first attempts at IPv6. Like what was going to take over for IPv4.

And it’s kind of entertaining to read. And I read 464XLAT because I really wanted to know what the acronym “XLAT” stood for, and I still don’t know. But it’s basically a way of v4 devices to connect over a completely v6 Internet. It’s basically like a fancy NAT, multiple layers of NAT that you use. And it’s used a lot in China actually because they do a lot of v6-only networking now.

The IEPG is this mysterious group that’s met for 20 years the Sunday before IETF. And I just found a long-term IETFer on my way back from Prague who didn’t know it existed. So there’s are a lot of people at the IETF who still don’t know it exists, even though they have been attending. But he wrote it down because he didn’t want to forget.

It’s a group of operators that meets – maybe a few of you are here, I don’t know, sometimes Rudiger’s here – anyway, it’s pretty interesting. I wasn’t at the IEPG meeting in Bangkok because our plane had a cracked windshield and we had to divert to San Francisco. So I missed it.

So the IEPG part is all from Prague. So there’s some work being done to measure QUIC. So QUIC is the new Internet protocol that runs over UDP. So instead of TCP – I mean, TCP over IP, it’s QUIC over UDP.

And they’re doing some measurements – mostly this is used heavily by Google and YouTube, a lot of the big content providers because it’s faster.

But apparently it’s only faster if the packets arrive in order. And once the packets start being out of order, there are some problems. So there’s some work being done to measure and figure out, like, is it really better, is it not better. So there’s a link to that information.

There was some talk about using BGP to blackhole DDoS attacks using BGP communities. There’s a lot of work being done with that. And then trying to make sure that you can’t maliciously use BGP communities to blackhole traffic, because that’s always an issue, too. So that was a presentation at IEPG.

So when a host gets disconnected from a network and a – in v6 and it gets a new address via Stateless Auto-Configuration, it doesn’t let go of its previous address even though somebody else might have that address.

So there’s some problems – there’s a lot of various v6 deployment problems. And this is one of them that’s being documented where you need to really be able to let go of the address that you just lost because somebody else might have it and then you might not be able to talk to the person who has it because you think you have it.

So this presentation was all about that. Okay. So the IETF is trying a new approach where they’re trying to get all the stakeholders together for a particular part of the work that we do in order to make it so that maybe we’re not writing a standard VET chip developers can’t put in silicon or various things like that.

So the first one of these was this deep dive into router architecture. And they decided that the acronym stood for We’ve Got – We Got Lego. I don’t know. Kind of weird. I don’t understand how WGTLGO means We Got Lego.

But anyway, it was a really interesting afternoon talk about router architecture. And some of the quotes, well, assuming a zero-gravity router was irrelevant, but I thought it was funny.

But some of the realities are that the protocol designers are saying we want a 128-bit, whatever, and the hardware designers are saying we can’t do that. And there’s this disconnect.

And so, like I said, some of these quotes are actually really the heart of the problem that we have. And so it was really cool to have all these people in the room, even though everybody was a little upset because the chip guys didn’t want to do the 128-bit and the routing guys are mad because the configs are humongous because they have to do everything in an access list.

So it’s kind of cool. I think they’re probably going to do some more of these where we try to get everybody on the same page as to soup to nuts from how the policy affects the people actually writing the code and doing the hardware.

Okay. So the key signing, key rollover, everybody knows about that, right? For DNSSEC, we rolled over the key. We got rid of the old key.

So in Bangkok, we had a meeting. It was a preliminary meeting to just talk about, okay, we rolled the key. How often should we roll the key? Should we ever roll the key again? It was a real pain to roll the key, all that kind of stuff.

So they had the afternoon on Friday, they had no meetings except for these side meetings. So I went to this one.

And so these are all the questions that came out of that, like I said, should we roll the key; should we roll it regularly; should we never roll it? They’re still really trying to work that out.

And then that rolled into this Futures BoF that happened in Prague just a week ago, which was a follow on of the same process. So now that we’ve not only rolled the key but we’ve made the old one invalid, what happened, and what was the fallout?

And there were some people who talked about how there were 250 million users adversely affected, but I don’t really – but nobody really knows, because the DNS is so dense and opaque, and it’s really hard to measure. And maybe a lot of places just turned DNSSEC validation off and left it off so they didn’t have a problem.

So really trying to grapple with how do you measure these things and figure out what happens when you roll the key and what really is broken.

So it’s a lot of work being done on that. I’m not sure if there are any really good answers at this point.

So DHC, Dynamic Host Configuration. This is a little bit from the chart. All of these at the beginning have a little bit from the charter so that you can know what the group is about. But basically this is DHCP in all of its forms and automatically configuring host addresses.

It was started in 1989. It’s the longest running working group. And we’re hoping that after November, when DHCPv6 becomes a full Internet standard, maybe the working group will go away. But that’s where we are at with that. So, again, DHCPv6 isn’t actually a full Internet standard yet; it’s just a draft standard.

So one of the things that DHC is working on is there’s so many devices on the Internet that are short-lived or they’re Internet of Things, little gizmos in your house. And they don’t really want to hard code MAC addresses into those devices because, of course, just like IP addresses, MAC addresses are a finite resource.

So stranding a bunch of MAC addresses in little gizmos that you threw out the year before is probably not the best thing. So they’re working on this whole link layer, being able to assign MAC addresses with the DHCP instead of having them hard coded in the hardware.

And half of the Mac address space was split into this local amount of address space. And it’s broken into these quadrants. And so part of the protocol that’s being worked on is how do you tell the hypervisor board that it’s this quadrant and then give out the MAC addresses to the little devices. So that’s some work going on there.

So link-state routing I started following just because I think that the data center – link-state routing in the data center I thought was interesting to follow because you have these really dense data center networks and link-state protocols are really chatty.

So there’s a lot of work being done – almost kind of too much work being done, like a whole bunch of protocols trying to solve the same problem, just like we had with all the tunneling protocols to get v4 and v6 working. Now we have a whole bunch of protocols to make data centers less chatty.

So that’s mostly what these slides are about. There’s a bunch of different modifications to the protocols so that there’s less flooding and so that your data center doesn’t melt down when things move around.

Let’s see. This is another algorithm for limiting the flooding. There’s another hierarchy to IS-IS that’s being proposed to limit the amount of chattiness in your linked state protocol. So that’s mostly what’s going on in that group.

DNS operations is, of course, all about the operations of the DNS system. Everything that could go wrong and more about the key signing key we talk about in there, that sort of stuff.

This draft we’ve talked about before basically lets resolvers downstream from the root be able to serve stale data in case the servers up above are being DDoS’d. And that really makes a lot more resilience in the DNS if you can at least use the information you have, even if it’s timed out, when you can’t get new information.

Let’s see. This is a new record type in the DNS that functions and – ostensibly like CNAME does, but it gives you – CNAME has a bunch of limitations and can’t exist with other resource types. So it’s a way of updating the CNAME functionality so that it’s more useful for a bunch of different features that people are trying to do.

This is a way of locating – okay, so for a while we were trying to put everything in BGP, like adding more and more stuff. And now they keep adding more and more stuff to DNS. So this is adding different services that you could find but adding it to the DNS. So, like, you could find your blockchain in the DNS, and you could find various other infrastructure and people and stuff in the DNS. I’m not sure how far that will go. But we’ll see.

These are some other drafts I’m not going to talk about that are going on in v6ops.

So they stopped having the technical plenary, but I always go to the plenary. And this time it was all a bunch of record keeping and this and that, but this slide I just think is hilarious.

So basically this is a sign on a building that basically says nothing ever happened here and hopefully nothing will ever happen here in the future. I just think it’s funny. Sorry. A little levity.

Okay. So computing in – so there’s the IETF and the IRTF. The IRTF is a resource forum that works in parallel with the IETF and does things that maybe the IETF isn’t quite ready for.

And occasionally – well, I go to the IRTF working group to see more, like, futuristically what’s coming down the road. And this research group is all about moving, computing as close to the end as possible, so out in the network, having your switch do things that are closer to you.

And the concept is that the edge is constantly changing. The edge of the network isn’t really the data center anymore. It might be your neighborhood or it might be various community groups or whatever.

And so, for example, in industrial networks, you know, that second that you’re talking to the thing that’s welding the part, maybe you really want it to only be a second delay, not a 20-second delay to go up to some data center.

They’re working on ways to push computing closer and closer to the actual thing that’s moving that you’re trying to make work out on the network.

Like I said, neighborhood clouds is another computing concept that they’re working on. Like, maybe things happen more – we still, we already do this, right? Your little cable modem at home does your DNS for you and it does your NAT for it. And it does little bits of computing that you don’t have to go all the way up to your ISP to do.

And this is sort of more of that. And I’m not sure that like a lot of those little devices and routers and stuff will be able to do any of this computing. But it’s a really interesting thing to think about.

Okay. So operation security is exactly what it means. It’s all about security out on the network and securing the network. So this is a draft that started quite some time ago, and it’s almost ready to be published. So if you’re interested, you should check it out.

We asked that they remove references to PI address space and some things that affect this community because they really have nothing to do with security. They have a lot to do with whether you can move your stuff from one ISP to another, but that’s not really a security issue.

So they’re cleaning up some of those things. And then this should go out for Last Call pretty soon. Since 2012; I think it might be time.

And in v6 Operations, so there’s – v6 Operations is just – it’s all about operating a v6 network and the interaction between v6 networks and v4 networks. And I’ll talk about the partner to this group in a little bit. That’s what v6ops is. Anything we need to make v4 and v6 work or to make v6 work operationally is what this group does.

Let’s see. This is getting your NAT64 prefix from your router. So when you’re just a v4-only host, you need to get an address to get on a v6-only network. And this is the protocol to allow that easier than now.

This is real life. They do a lot of v6 in China. And this is a survey of CERNET2, which is a big education and research network in China, and they’re not at all dual stacked. So they do v6 natively and then they translate on the edges. And they’re working on ways to make it so that they’re not doing multiple v4 to v6 to v4 to v6; they’re just doing one translation and then going to the other end and untranslating.

Let’s see. So this is deployment guidelines if you’re going to do translation. So like if you have a v6-only network and you’re going to – you still need your v4 stuff to talk to the rest of the Internet. There are operational considerations that you should check out that might help you in deploying.

And then the partner one to this is a comparison of all the transition mechanisms that you could use if you have a v6-only network and you want to make sure that all your v4 hosts will work.

And a lot of these are being used. There’s been talks that I’ve given before different organizations that are using MAP-E or MAP-T, and this is basically a comparison of all the different mechanisms.

So, again, this is more translation information for CDNs. And so the IRTF, like I said, is the research forum. And there’s a contest every year of papers that are like – they win the research award, Advanced Networking Research prize. And some of these are really great. I always try to go to this because the papers are really interesting.

This is all about – Facebook built this. They call it Edge Fabric. Basically it’s a real fancy – I’d call it maybe a route server that takes a whole bunch of notice of the speed and the bandwidth and the congestion on the different paths and then routes the outbound traffic based on different criteria.

And they’ve had some really good results. I worked at a company that did something similar, like, in 2002, and it can be really helpful, especially in their case because all of their customers are just sucking down a lot of data.

If it was – so they’re optimizing the traffic from their customer to them – from them to their customer, sorry, because most of the bandwidth goes that way.

So this is a really interesting talk. And then this is all about BGP communities and how far they propagate in the network. And I took out the slide – there was a little bit of a talk about this in IEPG as well.

I only have 60 slides this time because I tried to get rid of as much duplication as I could. But BGP communities are used a lot, and they go really a lot further in the network than people think. And it’s kind of a little bit scary. So that was cool.

Let’s see. And then they also talked about QUIC – again, that new protocol – and just how does it work with – compared to TCP and does QUIC on the network affect TCP performance.

So there’s a ton of work being done now that it’s being used fairly widely. There’s a lot of implementation.

So this was about that. And then I went to this group, MAPRG, basically measuring different protocols. And I think they talked about QUIC, too. But I took it out.

So there’s privacy and security in v6 networks. That was a talk that they had. And, again, more QUIC performance over satellite this time.

And some other measurements that they’re talking about in the group. So Homenet. I’m probably going to phase out going to Homenet because they’re as far as they’re going to get for a while, and they’re going to do marketing slides how they get more people to do Homenet, which is kind of – so, yeah.

And there’s some – I think we really have – because a lot of the v6 networks are dual stacked with v4, a lot of – we have a few problems because of that, but it hides a lot of things.

And a lot of these – they’re starting to do these home networks that are v6-only, and there’s a lot of problems, like how do we secure it, how do we send keys around, what do we do when there’s nothing there to configure it.

So they’re starting to look at like having a code on a device like a bar code that you scan, and then the network knows, oh, that’s a legitimate gizmo that you’re plugging into your network and that does whatever and that’s how you can configure it.

It’s just hard to try to standardize something that there’s no one physically there to configure. So I don’t know. But having keys and credentials for different things that get sent into a Homenet.

How do you get your naming, all that stuff, is still being worked on. And they’re not easy problems to solve.

Okay. So like I said, v6ops is all about v6 and v4 interacting in the network and making sure that it works.

And v6MAN is all about just v6 protocols so the real protocol work happens in 6MAN. They’re putting out a node requirement draft, and I think I’ve talked about it a few times since I’ve done this presentation, and the segment routing header. I’ll have a rant about headers in a little bit. They’re starting to finally finalize those.

So if you’re a v4-only host and you connect to a v6-only network, this is a way that the network can tell you don’t sit around and wait and wait for the timeout to get your v4 address, because you’re never going to get a v4 address, just go and use v6 already, because that’s all there is.

So this is something that the v6-only networks have really experienced. Like a v4-only host takes forever – like a host that starts out as v4 takes forever to come up and use v6 because it has to timeout, and it shouldn’t have to. If you’re only v6, you should just use v6.

My little rant about headers. We were having a discussion about MTU, minimum packet size on the network, and how it’s really out of date because it’s an IEEE standard and Ethernet is 1500 bytes. And with v6 and all the headers and all the stuff, the packets are huge. And the network, there’s still no good way to discover what the minimum packet size you can – I’m sorry, what the maximum packet size you can send without it getting fragmented and not working.

So there are two different options being worked on in 6MAN. One is the hop-by-hop option where you discover your MTU on hop by hop. And there’s a “Packet Too Big” message thing that happens and – I think I skipped it; I think it’s this slide – no. I’ll get to the other one.

So there’s quite a bit of work being done on that because in reality packet size should be like 9,000 bytes. And as the lengths get fatter and fatter, you want bigger and bigger packets so you can more effectively fill the link. So we have to figure this out at some point.

And as we add more and more headers and we do more and more tunneling and all those sorts of things, the packets just get bigger and bigger.

Let’s see. So this is a big discussion about how to generate these kinds of Stateless Address Auto-Configuration and how to get your – I guess I already talked about your NAT64 prefix from your router advertisement. A lot of this stuff gets presented in multiple groups, so I try to figure it out – I mean filter it out.

So this is the segment routing header, another thing that’s going to make the packet even bigger. And it’s almost going to Last Call. And there’s several implementations now. So it’s probably going to happen.

And, again, now this is the other MTU discovery mechanism which is a “Packet Too Big” message that gets sent back. And the truncate – the truncate bit’s set, and then you know that you have to send a smaller packet.

And these are some other drafts that are going on in 6MAN, another MTU draft and some various other things.

So Global Routing Operations, I go to this occasionally because I like to see kind of what’s going on out there in the operator world of routing out on the Internet.

Let’s see. So like I said from that other paper, there’s a little crossover here. There’s communities everywhere. They propagate really far. And there’s a lot of ways to hack that and blackhole traffic that are really big concerns for the operator community, and they’re starting to work on ways to prevent those sorts of hijacks.

Let’s see this one. Using BGP measurement protocol to make sure that your prefixes go where you want them to go is what this one was about. Since we don’t really – we haven’t really rolled out BGP security on a really big level yet. So they’re trying to detect route leaks without the humongous access lists.

So this group is new, and I just wanted to point out that it exists. And it’s basically about securing all those little Internet of Things devices in your home and keeping them from being bots and spreading porn and whatever they do.

So they’re just starting to form like an architecture and information model and some various things. And they do a hack-a-thon before the IETF, and they’re starting to do a hack-a-thon of this securing of the Internet of Things.

So when there’s no IPv6 something going on, I go to some other group. And this was some afternoon session that I sat in on.

So for those who aren’t friends with me on Facebook, you missed my awesome live streaming from the IETF on my Facebook wall, where I go on and on about what is the quantum Internet anyway.

And one of my friends on Facebook, of course, is in charge of the research group. So she made a tutorial just for me. So I’m supposed to know now what the quantum Internet is, but I’m still baffled.

So there’s some of my notes from the Quantum Internet Research Group. I really do keep pondering: What is it anyway? Maybe if you’re a physicist and you talk really slow, you can help me. I don’t know.

But so they did have a tutorial in Prague on what is the quantum Internet, and I’m still – to me, right now, the quantum Internet is massive distributed computing, where you’re connecting a bunch of different research facilities over the Internet.

But I do understand that in the future we’ll be sending around things that it never occurred to us that we would be sending around on the network, I guess, maybe.

So I did a big road trip recently. And I listen to a lot of NPR on my road trips. And I don’t know, you guys probably all remember people in this room saying that with v6 it can address every grain of sand on the planet.

And I always joke that that’s all fine and good, but if you give it away a beach at a time, it goes away really fast.

So I was driving back from California, and there was an NPR – it’s so perfect for the Caribbean – there was an NPR thing on the radio about how in Jamaica there’s this beautiful white sand beach. In the middle of the night, they came with helicopters and bulldozers, and they just took the beach away. And there’s this whole sleuthing thing going on trying to find where the beach went and who stole it. They haven’t solved that yet.

But it got me thinking. It woke me up in the middle of the night because like we’re actually using sand faster than the planet can make more sand. And when you take sand and you make it into concrete or whatever, you can’t get that back and readdress it and use it again.

And I just thought it was sort of a metaphor for v6. Like we might be addressing things that we never thought of. We might be using it to make things we never thought of, and to say that we have 12,000 years’ worth is probably not realistic.

And so I just – I don’t know, I thought it was hilarious. So if somebody is from Jamaica and you know where the beach went – they’re thinking that the resorts on the other side of the island stole the beach, but they mix it in so the forensics guys can’t tell whether it’s the white sand from the other side of the island.

Anyway, it just made me think about v6 and how we think we have an infinite amount. Like you think we have an infinite amount of sand, but we don’t. Anyway, onward. It’s your thought for the day.

All of these, the Datatracker and all these things are really good references if you want to go check out the IETF.

And if you’re going to go to the IETF, please talk to me. I’m happy to help be your mentor or whatever. And there’s also some good information online about how to attend an IETF and not be offended by the geeks and all that sort of stuff.

So, I’ve been to Prague four times. And I didn’t ever really realize that the grand ballroom has this awesome mirror in it. So this is actually an IETF working group and guys standing at the microphone to ask questions. I just thought it was awesome. I, like, perched in the corner.

Anyway, questions, comments, if you were there and I got something vastly wrong or whatever?

Kevin Blumberg: Kevin Blumberg, The Wire. Today’s a special day, Cathy.

Cathy Aronson: It is?

Kevin Blumberg: It is. 50th anniversary of RFC. 50 years ago today. April 8th.

Cathy Aronson: Written by…

Kevin Blumberg: Stephen Crocker. Whether it’s the 7th or 8th, I defer. So to another 50 years to all of the rest of us in the room.

Cathy Aronson: I know, right.

(Applause.)

Michael Casadevall: This might be a slightly touchy subject, but has there been any discussions on possibly opening up the last remaining blocks of IPv4, the Class E space, for future transition five to ten years down the line?

Cathy Aronson: No. Because – well, there have been discussions. But the thing is that the amount of time it would buy us pitched against the amount of engineering and host changes it would take, it’s just not worth it. I mean, that’s basically –

Robert Seastrom: What Cathy said, we discussed that even for private space 10 years ago, and it got no traction because too much effort.

John Curran: Right. There’s been at least two Internet drafts that talk about that that were discussed in the IETF, both of which were panned by that community.

There have been drafts suggesting that to the IETF; both were panned in the IETF community.

Michael Casadevall: Thank you for that answer.

Cathy Aronson: Anybody else, or was that just everybody got everybody to the microphone? All right. Thanks, everybody.

(Applause.)

John Curran: Thank you. Okay. We’re going to have a brief break outside. Everyone’s going to get a chance to do a little stretching of their legs, relaxation, refreshments.

We’re going to come back in here promptly at 11:00 because we have two Recommended Draft Policies to consider. So I look forward – everyone enjoy your break, and I’ll see you at 11:00, 30 minutes from now. Thank you.

(Break from 10:29 AM to 11:01 AM.)

Recommended Draft Policy ARIN-2018-2: Clarification to ISP Initial Allocation

John Curran: Welcome back, everyone. If folks will come in and be seated. So I wear glasses. These are not my glasses. These are someone else’s glasses that were left. If you need a pair of glasses and you think these are yours, come find me.

Okay. We have the policy block starting. And I want to – do we have announcements? No, going right in. Very good.

So I want to start right in with Recommended Draft Policy 2018-2: Clarification to ISP Initial Assignment Size. And this is a Recommended Draft Policy. So I’m going to give you the formal review of its history to date.

This could be adopted after this meeting. The Advisory Council could recommend it for adoption to the Board of Trustees.

This started as ARIN Policy Proposal 252 and became Draft Policy in March of last year. It was revised in June. It was Recommended in November of 2018 and revised subsequently. It’s been presented at two prior ARIN meetings.

The staff understanding, 2018-2 provides criteria that organizations without direct assignments for allocations must meet in order to receive an initial amount of IPv4 space.

It states very clearly that all ISP organizations without direct allocations, direct assignments, reallocations or reassignments will automatically qualify for a /24 of IPv4 space.

They can qualify for more than that, but then they need to provide documentation, which would be up to a 24-month supply. It provides guidance for ISPs that hold reallocations or assignments stating they must show efficient utilization for those requirements consistent with 4.2.3 and 4.2.4, a very straightforward change and will make the processing fairly simple.

We’ll be able to implement that, and ISPs can get a larger block as described in the policy. So organizations that currently have resources will need to show the utilization. No difficulty there.

There’s no legal material issues with this proposal.

Resource impact. Minimal impact. It could be implemented three months after its ratification by the ARIN Board. We would update the guidelines, staff training, and there would be nominal engineering work.

So I’m now going to call up Kerrie Richards to give the AC presentation.

Kerrie Richards: Good morning, everyone.

All: Good morning.

Kerrie Richards: Good morning.

All: Good morning.

Kerrie Richards: All right. So the problem statement. As discussed in more detail in 2017-9 and in the previous Policy Experience Report, the criteria to qualify for an initial block of space in 4.2.2 and 8.5.4 are seemingly at odds.

This policy has been around since last March. We think that we’ve sufficiently ventilated it. We’ve sent it to staff and legal. We have implemented all of the changes that were suggested.

So the policy statement is to replace the current Section 4.2.2 with all ISP organizations without direct allocations, direct assignments, reallocations or reassignments automatically qualify for a /24.

These organizations are exempt from the requirements of showing utilization in previously held IPv4 space as we spoke about earlier.

So the progress since ARIN 42. In October we did the staff and legal. That was complete. Changes were made January to March of this year. It was sent to PPML. Not much comments. And it is our intention that we will put it to the community for Last Call after this meeting.

At this time –

Paul Andersen: Thank you. Good timing, too. My laptop randomly rebooted and decided to do a 30-minute update.

So, the microphones are now open for anybody in the room to come and discuss this Policy Proposal either here in the room, or if you’re online, we have someone in the room eagerly waiting to read your comments into the record.

Again, this is a Recommended Draft Policy. So even though I know the printed guide is not in distribution as much, somewhere on the website you’ll see there’s this lovely flow chart. So if you’re not familiar with the policy process, it gives a great breakdown of how a proposal gets there.

As I mentioned, this is the last time you may see it before it gets adopted. So it’s very important, if you’re in favor, against, to come to the mic and speak on that.

Not all at once, though, because we don’t want anyone to get hurt trampling to the microphones. Please. Going once – it’s very important input to the Advisory Council.

Front microphone, please, and please make sure to speak your name and affiliation.

Kevin Blumberg: Kevin Blumberg, The Wire. Can you bring up the policy text? And I guess the first thing is I’m neither for or against the policy at this time.

There was a little bit of confusion between the staff or the slides in that this says organizations without anything automatically qualify for a /24 – that’s what’s on this page – without direct allocations, assignments, et cetera.

But on the other page it said that these organizations are exempt from the requirements of showing the efficient…

In the staff – can you go to the staff one, please? Backwards, yeah.

Paul Andersen: I don’t know if we can go to that one. Can we switch back to the staff report? Sorry. One moment.

Kevin Blumberg: It sort of contradicted that. It said that organizations that do not have direct allocations, et cetera, et cetera. So staff are saying – or what it appeared to me to be was one was saying that an organization that doesn’t have anything can qualify, and the policy seems to say you’re exempt if you’ve got all of these things.

And I didn’t understand why there was that differential.

Paul Andersen: We’re just rereading as you raised this.

John Curran: Kevin, which is the – do you believe that the staff analysis is incorrect of the offered text?

Kevin Blumberg: I wanted to bring it up so I could double-check.

Paul Andersen: He’s trying to understand the difference.

Kevin Blumberg: Right, right.

John Curran: But you haven’t come to a conclusion one way or the other.

Kevin Blumberg: I haven’t. That’s why I was asking.

John Curran: Okay.

Paul Andersen: Normally we wouldn’t take – but since there’s no hoard at the microphone, we’ll just kind of… all right, there we are. Is this the one where –

Kevin Blumberg: So, first of all, they say, “must show efficient utilization of their current resources.” So that is in contradiction to the actual policy itself which says you qualify.

Paul Andersen: I think John has his interpretation.

John Curran: So the policy text says: All ISP organizations without direct assignments, allocations from ARIN qualify for an initial allocation up to a /21 depending on ARIN’s minimum size.

Kevin Blumberg: That’s existing text, correct, the /21?

John Curran: No, that’s –

Paul Andersen: That’s the policy statement.

Kevin Blumberg: Policy text, okay.

John Curran: So the staff says – you’re asking about efficient utilization of current resources.

So at the bottom it says “ISPs holding reallocations or reassignments must show the efficient utilization of their resources consistent with 4.2.3 and 4.2.4.”

Paul Andersen: It seems consistent with that.

John Curran: It seems consistent with that.

The third line of the proposed text is “ISPs holding reallocations or reassignments must show efficient utilization of their resources.”

Paul Andersen: Yeah, the first two paragraphs are those without one of those criteria. And the third paragraph is with. Does that address your –

Kevin Blumberg: That addresses my concern.

Paul Andersen: Did you want to comment on the policy, then? Sorry, Owen, I know you were coming to clarify.

Kevin Blumberg: My second question to this is: How does this affect things like the waitlist? Overall, I’m in support of this. It makes things a lot easier for everybody.

But when we are basically creating a situation of automatic approval in one section, does that then create and pose an issue for things like the waitlist?

Paul Andersen: The waitlist is suspended. So it effectively is as if there’s not one right now. So…

Kevin Blumberg: It is a generic question in that when things are automatically approved and if the waitlist was not suspended or there was a new waitlist, or whatever the case may be – I know there’s a number of other policy proposals – but does this proposal create – and maybe it’s for the other policies to know that if this policy moves forward, then there could be a –

Paul Andersen: Could I suggest – because I think the correct is that you would ask the AC to take into consideration as it looks at the waitlist proposal that’s been suspended, that it consider how this would impact it.

Kevin Blumberg: Right. Correct.

John Curran: Kevin, how would you like this to affect the waitlist?

Kevin Blumberg: I do not want this to affect the waitlist. I don’t think that anything that is automatic like that necessarily feeds into it. But it’s more I want an understanding that this would affect potentially things like – because it would allow for /24s – would this affect 4.10 as an example? Or does 4.10 sort of have its own things?

So if the AC can consider that, does it have impacts to other policies by this automatic approval, but overall I am in support of it.

Paul Andersen: You are in support. Thank you for that feedback. Front microphone.

Alison Wood: This is my own. Alison Wood, State of Oregon and on the ARIN Advisory Council. When you’ve been working on this, and to piggyback off where Kevin was going, have you gotten a read on how many ISPs are going to take advantage of this policy or what the general community need is?

Are we going to get just a flood of ISPs coming in asking for a /24, or is this going to be kind of a onesie-twosie thing where we are making it easier for the community but we don’t have a tremendous amount of ISPs that are needing space right now.

Paul Andersen: I think John Sweeting would probably have the best answer.

John Sweeting: John Sweeting with ARIN. This is initial. So ISPs that are there – this is for a new ISP that is starting out that has no IP space. They can initially qualify for a /24 by the basis that they are an ISP that it wants to provide service.

So it’s just the initial. So the effect – yeah, it would affect the waitlist. But it’s just the initial.

Alison Wood: Have you had a lot of people coming in wanting –

Paul Andersen: Do we have data on the number of initials that –

John Sweeting: I don’t have it off the top of my head, but I can get it.

Paul Andersen: Okay.

Andrew Dul: Andrew Dul, ARIN AC. I’d like to remind the group that the genesis of this policy is to fix a discrepancy between the transfer policy and effectively the waitlist policy wherein there are two different requirements for an initial ISP if you – depending on if you pull the transfer button first or if you pull the waitlist button first.

And the goal of this is to harmonize it so it doesn’t matter if you apply under Section 4, the previous waitlist policy, or if you went to go get approved for a transfer, the rules would be the same. That’s the goal of this, to make it the same for transfers and for waitlist or whatever.

Paul Andersen: Are you in favor or opposed?

Andrew Dul: I’m in favor of the policy as written.

Paul Andersen: Front microphone again. This time holding a device.

Alison Wood: Remote participant, Brian Jones. He wanted to state that he supports 2018-2 as written.

Paul Andersen: Thank you, Brian Jones.

I have depleted my source of speakers. So I would ask if you are online to start typing feverishly, or if you’re in the room and want to be able to have comments, to approach a microphone quickly.

After I close the microphones shortly, we will then go to a poll, a show of hands on those that support and those that are against. We’ll be closing the microphones at the end of this next comment.

Alison Wood: Jeremy Austin also states that he supports the policy.

Paul Andersen: Thank you to that remote participant.

With that – I’ll give the remote participants…is there anything else being typed?

Alison Wood: No.

Paul Andersen: With that, we’ll close the microphones. We’ll thank the AC for its presentation.

(Applause.)

This is audience participation time. If you are watching this either in the room or online, you are entitled to show your support or show that you are not in support of this policy.

So I’m going to ask – I’ll tell the question first. I’ll ask those in favor of advancing the policy as written, I’ll ask for those in favor and those against.

If you are in the room, please raise your hand and keep it raised until I ask you to put it down because our expert counters, who I think are in position, need to count.

On the matter of 2018-2, all those in favor of advancing the proposal as written, please raise your hand nice and high and keep it there. One hand only, please. Give it a second.

I can’t tell who is voting because, as you’ve already heard, there’s 17 blinding lights. I kind of see some hands in the front. I need my counter to give a very obvious sign when we’re ready.

Please keep it up. Thank you. You can put your hands down.

And now all those opposed to the proposal as written, please raise your hand if you’re in the room. Of course, remote participants need to follow the steps that are sitting on the screen beside us. Somewhere right here, I believe. Just waiting for the results.

Tonight is social night. After a full day of policy, we’ll go to our always entertaining and enjoyable social. So details to come soon. I see the envelope on its way down.

On the matter of 2018-2, we have 108 people participating in the room and remote. In favor, 40. Against, zilch. This will be provided to the AC for their consideration. Thank you.

John Curran: We’re going to move ahead. I am still in possession of a pair of glasses, fine reading implements. If you’re reading your Discussion Guide and it’s blurry, please come to the front.

(Laughter.)

Recommended Draft Policy ARIN-2017-12: POC Notification and Validation Upon Reassignment or Reallocation

John Curran: Okay. Thank you. We’re going to move on to the next Recommended Draft Policy, Recommended Draft Policy ARIN-2017-12: POC Notification and Validation Upon Reassignment or Reallocation.

Because it’s Recommended Draft Policy, I’ll do the introduction.

This started as ARIN Policy Proposal 247 in October of 2017; became a Draft Policy in November; became a Recommended Draft Policy last March.

It went to Last Call, and it was recommended to the Board for adoption and the Board sent it back. We don’t do this very often. But we remanded it to the AC last August.

And the reasoning behind that was effectively that it was – the way it was originally phrased it was a significant burden both to ARIN and to the parties involved. And we wanted to make sure that the AC was clear of that intent.

The AC revised it last month. And so this policy in various forms have been presented at ARIN 41 and 42.

Staff understanding – that’s interesting. It was revised in March. And the Staff and Legal Review was 28 February. Have we had a Staff and Legal Review since the revised text?

Owen DeLong: Yes, February was the last –

John Curran: It was revised in February. Okay. I knew that was the case because I’m never supposed to be here talking about a Recommended Policy that doesn’t have a staff and legal.

It was revised recommended in February – 25, I’ll bet, and we’re going to confirm that.

This is the Staff and Legal Review that occurred afterwards. Owen.

Owen DeLong: It was revised in February, recommended in March.

John Curran: Thank you. Okay. Wonderful. So, yes, it was revised. We did a Staff and Legal Review. And the AC recommended it in March. Okay. So everything is in order and we’re just double-checking things here.

Okay. So staff understanding from the revised text is that NRPM Section 3.7 requires all requests for reallocation or detailed reassignments can only be made to existing organizations at least one validated POC object.

This is a large change to how we do business. Several customers have automated their reallocation/reassignment process with ARIN following the current model.

These changes will add some complexity and possible additional states to automated systems interacting with ARIN. These changes will require customers requesting reallocation of detailed reassignments to gather and verify information prior to submitting their requests.

These changes will provide a higher privacy protection to the organizations that are having reallocation/reassignments submitted on their behalf. ARIN would be required to notify all POCs requiring validation through email notification, whether the request was successful or not.

So this will improve the accuracy of the data in the ARIN database. It will not have a direct effect on RSD operations because, as the policy’s been changed, they’re automated. There could be some increased support tickets as a result.

We can implement this policy as written. There’s no material legal risk to this policy.

There’s a pretty sizable resource impact, because we need to change the systems, particularly the ones that are used automatically by developers to submit reallocations and reassignments to do the necessary checking. Could be implemented with about eight weeks of development work.

It will take approximately six months to accomplish that in our current schedule, once ratified by the Board of Trustees.

So I’m now going to have Chris Tacit come up and give the ARIN Advisory Council presentation.

Chris Tacit: Thank you very much, John. Before I start the clarification about the timing of things, it was moved to Recommended after the staff and legal, but the staff and legal itself recommended a very minor wording change.

So there was a further change made to it after that, but that change is not material and doesn’t affect the Staff and Legal Review because it was based on the recommendation in the Staff and Legal Review.

All right. So here’s the problem statement. I’m not going to read it. But basically the problem in a nutshell was that with these automated reassignments, you could end up with POCs being created relating to individuals who had no idea that they had POCs or even understood what ARIN is, and it created a lot of spam for them potentially if there were multiple POCs associated with their email addresses and also created issues around POC validation.

So the Policy Proposal obviously wants to fix that particular situation, and essentially it does so in a much more elegant manner that actually my co-shepherd, David Farmer, came up with than the previous original text. And it basically does so by ensuring that there’s at least one valid POC object available before any such reassignment is linked to it.

And then once that happens, there’s a communication element to this where all the POCs associated with the same Org are notified, and there’s a request to validate any POC objects that have not been validated.

So John already went over the staff and legal. So I won’t belabor that. And the relevant history here is that, as I said, David’s rework and then our joint effort to finalize that wording we think is a much simpler way to implement this than the original text and obviously a lot cheaper and less intense for ARIN than the original proposal was.

There’s been very little said on PPML about this one way or the other since the language was revised more significantly. We think that probably means there is community support. But we would like to validate that today and ensure that such support does persist.

The reason we think that is because people were not shy about weighing in and objecting to the original language. And the fact that things are so quiet now suggests to us that there is support. But we obviously want to make sure that persists before going ahead and taking this to Last Call.

The other thing we want to make sure is that from an operational perspective, because there will still be some burden on those interacting with ARIN to implement this in their own automated systems, that they’re not going to be tempted not to record reassignments and reallocations, which would obviously result in a less accurate registry. We don’t want this to have a perverse and unintended consequence.

So those are a couple of the things that we’d like you folks to consider and comment on.

Paul Andersen: So no news is sometimes good news, but the AC does appreciate feedback even if it is just to state that you are in support. So hopefully we can fix the trend here from PPML.

So those that would like to speak in favor, against this revised policy that’s been taking a long and windy road, please approach a microphone. Yes, the long and windy road. Gotta pay extra for that.

Front microphone, please.

Michael Casadevall: Michael Casadevall, NARALO. I want to speak in support of this policy because having up-to-date and accurate POC information is incredibly valuable when dealing with network DDoS attacks or bad traffic of determining who owns a block, who to contact and being able to help mitigate issues from point to point. So the Whois is incredibly valuable, and more accuracy goes a long way. So…

Paul Andersen: Thank you for that support.

Others who would like to speak, please approach a microphone.

Front microphone.

Kevin Blumberg: Kevin Blumberg, The Wire. I’m in support of the proposal in principle, but I have two hesitations.

Staff and legal came back, and it’s still very, very – has a high cost and a high-implementation scenario. And I’m concerned that really we’ve tweaked the wheels and it’s going to go back to the Board and it’s going to get remanded again back, because I don’t really see a substantive, substantive change to what is fundamentally the issue of automation. So that was my first part.

And, John, if you want to –

Paul Andersen: I’m actually going to address it. It wasn’t sent back by the Board because it was too expensive. That was not – there were concerns also just about the deployment and whether the operator community had fully engaged, because sometimes we’ve had policies where they weren’t engaged.

To take a substantive effort, which is something we’re not opposed to if the community wants when we weren’t sure it was flushed out, would not be a good use. But because now the AC has taken extraordinary steps to flush that out, I don’t think the – I can’t speak what the final, but the eight weeks does not – we’ve had policies that have been higher implementation costs.

Kevin Blumberg: I wasn’t referring to expense in terms of dollar figure. I was referring to expense in terms of the cost to the community to fix their automation, costs to ARIN to fix its – it’s an overall – the human hours, the people hours, the concerns there.

So that’s what I meant by “expense.” If that has been significantly lowered –

Paul Andersen: I think the AC will have to evaluate and the Board when it gets referred.

Chris Tacit: Just so you know, in terms of the sort of extraordinary consultation that we did undertake after it was remanded to us, we actually went out to the operator community and we held sessions during the last NANOG to try and get input from operators as well on what would be acceptable to them and so on. So this is largely a product of that effort.

Paul Andersen: Thank you, Chris.

John.

John Curran: As Paul – I don’t know what the full Board will do with this, but recognize that the original proposal, it wasn’t clear that that engagement had happened, and now it’s clear it has.

Additionally, there’s nothing wrong with us doing development work for what the community wants. That’s why we’re here. We do it all the time.

The original proposal had a creative/innovative process for addressing organizations that couldn’t be added and needed to be remanded that involved tickets and RSD team.

This process is a lot more straightforward. The combination of the outreach plus a straightforward process means this is a very different – even though it’s still a lot of coding, it’s a very different impact overall.

Doesn’t change the impact to the community who has to work with it. Doesn’t change the impact or the fact that there’s coding that has to be done, but a lot of the aspects of this have been resolved.

Paul Andersen: Another comment, Kevin?

Kevin Blumberg: In answer to Chris’s question, I believe that this will lower the amount of detailed assignments. People will move to simple when there’s that chance. From an automation perspective, it makes no sense to do this when you can go to simple, and they will make that determination obviously on their own company.

So I do see us moving more towards simple. We should have been there in the first place.

I absolutely support this because I’m tired of seeing my name or other people’s names showing up on records when they shouldn’t have in the first place. So this is addressing the real issue, which is that individuals don’t have a way of getting themselves off of it. They need to be validated in the first place.

But this is not going to improve, as was brought up earlier, accuracy because we’re going to see simple assignments without any information, which I think is actually more appropriate in this case because what you would have gotten is bogus information as well. Thank you.

Paul Andersen: Thank you for that comment in support.

Front microphone, still.

David Farmer: David Farmer, University of Minnesota, ARIN AC.

I would like to invite any ISPs that are making large amounts of detailed records to come up to the mic and please inform the community what you might do.

I’m not going to name names because that’s not appropriate.

Paul Andersen: Please do not name names.

David Farmer: Yes. But, please, if you’re in the room or online, please make some comments. It is important that you do this.

Paul Andersen: Alternatively, also feel free to catch at lunch – the AC is around all week.

Front microphone.

Please approach a microphone if you wish to speak, because we’ll have to close as we’re getting to depleting speakers.

Alison Wood: I have three. I may need those glasses.

Brian Jones (remote): My organization does not currently use automated reassignment methods. With that said, I support the policy as written. Valid contact information is very valuable to the community at large.

Then I have Jason Schiller, Google, ASO AC: Can we clarify if ARIN will notify via email all POCs associated with the receiving organization includes, possibly optional, all emails of ARIN Online accounts linked to the Org ID?

Jason also says he supports it as written and he would prefer greater support of unwitting POCs to set things straight, but this is much better than our current situation with where these are discovered during annual resource review.

Paul Andersen: John, the question there from Jason there, does staff interpret that text that you would email – would you email all contacts on ARIN Online? Could you read his question one more time?

John Curran: All the contacts associated with the organization. That’s not the same as all the accounts. That’s a different thing.

Alison Wood: Right. He says: Can we clarify if ARIN will also notify via email all POCs associated with the receiving organizations including all emails of ARIN Online accounts linked to the Org ID?

John Curran: If you have an ARIN Online account, which is tied to a POC, which is part of the organization, then the POC will get notified, and so you’ll get that notification.

It is possible, if you have an ARIN Online account that’s not a POC and you wouldn’t get notified, only notifying the POCs on the organization record.

Paul Andersen: Jason, let us know if that addresses your question.

You said there’s one more.

Alison Wood: One more, Dawn Bedard, Microsoft: The challenge of the ISPs creating POCs automatically is a problem. I spend a lot of time where I get emails internally when this happens, and we ask them to tell the ISPs what the correct contact information is.

We have worked very hard and are still working on standardizing POC information with RIRs. I support the proposal but am concerned that the implementation will not happen.

Paul Andersen: Okay. Did you want to address –

Chris Tacit: So when they say implementation will not happen, will not happen by whom, I guess, is the question? At their end? Is –

Alison Wood: I don’t know. As soon as Dawn responds, I’ll come back to the microphone.

Paul Andersen: We’ll close the microphones at the end of this comment, with the exception if the two remote participants want to address the questions we proposed, we’ll take those. But please approach a microphone quickly because we’ll close the end of this comment.

Jeff Anderson: Jeff Anderson, Implex.Net. I support this as written. I think anything we can do as a community to increase the accuracy of our dataset, we should do. We realize there’s an impact to implement this, but I think it’s worth doing.

Alison Wood: Dawn responded. She said, “By the ISP.”

Paul Andersen: Did Jason indicate he wanted to –

Alison Wood: No response.

Paul Andersen: If somebody does want to ask questions, you can get them during the lunch break. Thank you so much for the AC and their presentation, Chris.

(Applause.)

My expert pollers are in position. We’ll ask the same style question as the last one, as this is a Recommended Draft Policy.

First those in favor of 2017-12 advancing as written and those that are opposed. If you’re remotely participating, please show your indication now.

If you’re in the room, all those in favor of 2017-12 advancing as written, please raise your hand nice and high.

Thank you. You can lower it. And those opposed to 2017-12 as written, please raise your hand nice and high.

That’s an opposed hand?

Chris Tacit: No.

Paul Andersen: I was confused. I’m glad I asked. Pollers, did we get that? Just a moment, and we’ll wait for the results.

Are we getting an early lunch or announcements – we might get an early lunch, I think, after very important announcements.

All right. Thank you for your patience. Thank you, sir. On the matter of 2017-12, total participants in room and remote is 113. In favor, 41. Against, one. This will be provided to the AC. And this concludes our policy block.

John has announcements.

John Curran: Okay. That concludes our morning sessions, and we are going to have lunch right after this. Two quick announcements.

First, at the lunch, there’s lunch table topics. If you want to talk about a particular topic, walk around the lunch area, you’ll see these little signs.

That table, people interested in that topic should converge on those tables. And certainly these topics are interesting. So I recommend you take a look: Whois database cleanup, IPv4 Waiting List. Transfer policy is always popular. PPML participation and training at ARIN. And joining the AC. That’s a good table.

RSD Help Desk is open and out there and available. Good time to come by and work on anything you might have with Registration Services. It will be opened during CaribNOG for the rest of the week.

Security. The room is not locked. Take your valuables with you. We’re going to be back here at 1:30. We’re going to consider third-party organization record creation and reassignment requirements. We have two policy blocks, two policies to consider, Recommended Draft Policies.

We will start promptly at 1:30. Okay. At that, enjoy your lunch. They’ll be setting up in about five, ten minutes outside. So just want to let you know. Five, ten minutes before lunch is ready. But you’re free to take your stuff and look at the beach.

(Public Policy and Members Meeting adjourned at 11:40 AM.)

Recommended Draft Policy ARIN-2018-5: Disallow Third-party Organization Record Creation

John Curran: If folks will come in and be seated, we’ll get started.

We’ll start with the announcements. So this afternoon’s agenda. We have one Recommended Draft Policy, ARIN-2018-5: Disallow Third-party Organization Record Creation.

We have a number of draft proposals: 2018-6: Clarifying Reassignment Requirements; 2019-1: Clarifying Section 4 IPv4 Request Requirements; 2019-3: Updating Section 4.10 for IPv6 Deployment Block Assignments.

We have a presentation on our website and routing registry update. We have a presentation of a report that was done, a study on IPv6 economic factors for deployment. And then we’ll have a discussion of community input on future meeting agendas. And that should be this afternoon. Should be a good day.

We are going to start right in. At the head table, we have the same people. We have Paul, our Chair of the Board; Bill, our Vice Chair; Tina, Chair of the ARIN Advisory Council; Leif, Vice Chair of the ARIN Advisory Council.

(Applause.)

Applause because that might be the first time in 20 years I’ve gotten it right from one end to the other.

So there’s someone out there feeling their way around the Hilton. If you see them, bring them to me. Their glasses are still here. They were left at the back of the room at the first break.

Okay, so let me start right in on the Recommended Draft Policy.

Recommended Draft Policy ARIN-2018-5: Disallow Third-party Record Creation. This was a Policy Proposal in October of 2018. They adopted it the following month as a Draft Policy.

So draft policies – let me talk about that. Proposals are things that you guys have an idea. You send us a proposal. It defines a problem. Might suggest some text.

When the AC says, “Yeah, that is an actual understandable problem,” they may not agree with your problem, but they understand it’s something to do with the Number Resource Manual and it has a fairly cohesive statement of what you’re trying to fix, then they’ll adopt it. And it becomes a Draft Policy.

At that point it’s under ARIN Advisory Council control, and they watch the postings on the Mailing List and they take input from everyone and use that to revise it based on community feedback.

This became a Draft Policy in November. Based on feedback, it was revised a few times, ended up the last revision was February 4th of this year.

It was recommended for adoption in 2016 – I’m sorry, 26th of March 2019. So that means that the AC has found it meets the criteria necessary for a good policy.

That means that it has a clear problem. It has a – it’s technically sound. It is something that is supportable, supported by the community.

They’re going to confirm that at this meeting. So that’s why we’re going through this. So this is the first time being presented. If it has support from the community at this meeting, it could actually – as a Recommended Draft Policy, it could be sent to the Board to be ratified and put in the Number Resource Policy Manual.

So Staff and Legal Review. 2018-5 requires that only an authorized contact that is verified by ARIN be allowed to create a new organization record. The request must be submitted directly to ARIN by the organized contact and no third-parties shall be allowed to create organization records on behalf of the new organization.

This means that organizations wishing to reallocate/reassign address space to their customers must coordinate with the customer to ensure they have created an Org ID first. We’ll need to ensure that no matter which method is used to reallocate/assign, the Org ID will be verified prior to creation.

It will have an impact on registration services as there will be more organizations created; therefore, more questions, more tickets.

These changes will result in more accurate information. The development for system changes, about four weeks. It can be implemented as written. There’s no material risk to this policy.

Resource impact. Medium resource. It can be implemented probably three months after ratification by the ARIN Board. It changes the guidelines, procedures, documentation on the website. There’s an additional workload to RSD for processing Org create tickets that we anticipate. Medium level of engineering effort is required.

So that concludes my introduction to it. I’ll now have Andrew come up and give the ARIN AC presentation.

Andrew Dul: Good afternoon, everyone. I hope you all had a good lunch. Let’s jump right into Org IDs. So, what is an Org ID? Is it a strange creature? Something else? Maybe this is an Org ID. No, this isn’t an Org ID. This is actually a hoary marmot that I found in Mount Rainier National Park.

Let’s get on to Org ID. Organizational record is actually an Org ID. It’s basically a top-level database record that we have in the ARIN database that defines an organization.

We kind of have a sample one here on the slide: Bob’s Bait and Sushi, just down the street here on Waterfront Road.

And most of the time Org records are referred to by IPv4 and IPv6 blocks, ASNs, and they also have Point of Contact records associated with them.

Okay. So how do we create an Org ID today? You can do it in ARIN Online. You can still do it via email templates. There’s three different templates – actually, there’s five different templates you can do it with: an Org template; reassign detailed, either v6 or v4; or a reallocation template; and you can also do it via Reg-RWS, which is the API instance into the ARIN database. So there are many different ways you can create the Org ID today.

This is a long problem statement. I won’t read it to you. It’s also in your packet, for those of you who have it, or on the website.

Basically the premise of the issue is that the way that we create Org IDs today creates a whole bunch of database cruft. When people create reassignment records, they basically often just add an additional Org record just because it’s easier rather than assigning it to an additional one.

And we want to stop that practice so that we have organization records that actually represent real organizations that exist in the world. So, how do we do this?

This is the text that is going to be changed. Basically adds a little section that says that we’re only going to create organization records from authorized contacts representing that specific entity.

So if you’re an ISP, that means that – and you’re going to reassign a record to someone else, it means that someone else has to come to ARIN and create an Org record for you to create a reassignment or reallocation record for that specific organization.

What’s the effect of this change? We kind of already highlighted this a little bit. The authorized representative has to be verified by ARIN, and they are the only ones that can read an Org ID. And ISPs have to get the organization themselves to start with ARIN first before a reallocation or reassignment record can be created.

So, what of the outcomes that we hope to have from this? We hope to reduce the number of Org IDs in the database overall and make them more accurate because they actually represent records that are created by organizations rather than alternate records that are created by ISPs.

So the discussion points. Do you support this policy change? And specifically, if you are a large or other ISP that makes a number of reassignment records or reallocation records, we want to hear from you on this, just like the POC change that we discussed about earlier today.

This could be a significant impact on your workflow. And we want to make sure that we’re taking that into account as we make this change and make sure that we have the correct timeline for implementation that will meet with many of the organizations around there, around our region.

And do you have any issues or questions about the implementation or any other suggested changes?

One comment about – that had come up on the list since we made the slide deck is a clarification to make sure that people who are acting as contractors for small organizations are able to continue to make those records.

And so any comments about that, what would constitute an authorized contact, we’d like to hear from you in the room on that discussion. So, thank you very much.

Paul Andersen: Thank you, Andrew. Microphones are open. Recommended Draft Policy. Same drill. I know food always slows down a bit. But I’m sure that somebody will approach the microphone quickly. Someone might even want to be Kevin. His nemesis is approaching the mic. Front microphone.

Owen DeLong: Owen DeLong, ARIN AC. I don’t think I’m Kevin’s nemesis.

(Laughter.)

Paul Andersen: For getting to the mic first.

Owen DeLong: He had clear advantage earlier. I don’t know what he did. Regarding the Policy Proposal, I support it as written.

I think that this is an important problem to solve. In my previous employ, I spent a great deal of time tracking down and eradicating Org records and POC records and all kinds of other records that were created on our behalf erroneously by various contractors that a random person in the company had contracted with and they had just sort of put information in there that felt good.

And this led to much badness. So this is a definite needed thing and I hope we will move forward. Thank you.

Paul Andersen: Thank you. Next speaker.

Louie Lee: Hi, this is Louie Lee. This is Louie’s hood.

Paul Andersen: Tell us what happened to Louie’s hat.

(Laughter.)

Louis Lee: Find me at the social.

I’m with Google Fiber and also on the NRO NC. And in my previous job I was at an IX operator who operated a small transit service, and in doing so our transit service is PGP-based and required our customers to obtain an AS number, many of whom did not have AS numbers previously.

I’m telling you all this because it was not that much of a burden to help them create an Org ID. It was a matter of walking them through the application, the form, and let them know, go ahead and come back to me if they have issues. If they really needed an Org ID, it’s fairly simple to have even a form that’s partially filled with my information that I need them to have.

However, I’m interested to hear from anybody that operates an ISP that have large numbers of customers who they really want Org IDs for. I had only a small number. But the work per customer was not that big.

Paul Andersen: But are you in favor or against?

Louie Lee: I’m in favor.

John Sweeting: John Sweeting with ARIN. I’m neither here nor there on the policy –

Paul Andersen: As we would expect.

John Sweeting: As would be expected, but I just want to say that what Louie just said is very good, but also if there’s ISPs that want their customers to create Org IDs and they don’t want to spend the time with them, there’s a help desk number that they can call and we will walk them through it.

We can, as of now even, generate the tickets for them and give it to them to resubmit to us. So that’s all there and good.

Paul Andersen: Thank you. Next speaker, please.

Kevin Blumberg: Kevin Blumberg, The Wire. On the online stuff and the manual processing and the using the help desk, this is all easy-peasy stuff, and I absolutely support it.

But if you look at this morning and the impact to the API, this would to me completely destroy the use of the API for creating Org IDs because you’d have to have an Org ID created in the first place.

I don’t understand the severity of the impact. And that wasn’t really determined here by staff. What is the severity of the impact to the API? Because ultimately that’s the group that’s going to have the biggest issue if this policy, to my mind, is implemented.

So what is the scenario in terms of the breakage when this is now disallowed through the API?

Paul Andersen: It’s a good question because obviously automation might be tricky, but Andrew says he can…

Andrew Dul: So, I think what would happen – and I think there’s also a question for staff on how the implementation would work – but my suggestion is is that create from a Reg-RWS would no longer be permitted inside that system.

I would still expect that modify and delete would be available because there are other fields that you might want to change without directly interacting with ARIN via a ticket. But if there are other folks who use that Reg-RWS more than I do, that would be good information to know.

Paul Andersen: John.

John Curran: Create is not a very popular call today because it requires work to process in any case.

You’re talking about a circumstance where organizations that we have right now end up with Orgs created indirectly. And that’s a different creature.

Your question is, how does the API change. Unlikely the API will change. It’s just more likely you’re going to end up with a ticket that has to be manually covered in order to provide the documentation to confirm you’re an authorized contact. And I don’t expect a lot of the automatic people will bother to do that. Because they don’t have the documentation and they’re not the valid contact, eventually the request will be closed out.

So you’re trying to distinguish two different things. If you want to know about the API, we’ll look at what happens to the API. It’s quite likely it will become very rarely used. It doesn’t mean you delete it; it means it becomes very rarely used.

The different question is what about organizations right now who want to create Orgs on behalf of their detailed reassignments? They can’t. And that impact is the same whether they’re using the RESTful interfaces or not.

Paul Andersen: You’re saying, John, that currently the create API would be automatic under this? It would now go for manual processing?

John Curran: It would require a verification of an authorized contact, which means it’s going to be manual.

Kevin Blumberg: So the flip side to this policy – and, again, I’m in support of it – but the flip side to the policy is that in preventing erroneous records, we are more than likely going to prevent legitimate records because it becomes complex, and therefore Orgs are just going to turn it off. Would that be a fair statement?

John Curran: If you believe that the records that have been created historically are authorized – historically they’ve all been “authorized,” even though they’re created by another Org, then you’ll be losing those authorized records that would have been created, yes.

If you believe that most of the records that have been created are not authorized by the organization they’re being created on your behalf, then that’s what you’re losing. You’re going to lose a mix of – you’re going to lose Org records that would have been automatically created.

The question is how many of those that were being created would have actually been qualified by the Org that they were created on behalf of. It’s a very, very, very, very small number.

Paul Andersen: Does that address your question, Kevin?

Kevin Blumberg: I would use “accurate” versus “authorized” because if the record is accurate, I really don’t care; it’s accurate. That’s all I care about as an end user. But I don’t think that’s the case right now, and I think this is why the policy is there, is because most of the stuff is not accurate. It’s wrongly placed. And the people that should have had a say, the authorized people in the first place, didn’t get a say.

John Curran: And if it is accurate, it’s a transient event that changes over time to become less accurate nevermore.

Paul Andersen: I think we’re getting into the rabbit hole –

Kevin Blumberg: Thank you, that answers my question.

Paul Andersen: That’s an identified question that the AC should probably at least address and work out with staff.

Michael Casadevall: Michael Casadevall, NARALO. I’m tentatively supportive of this policy as written, but I have concerns for companies that manage other companies’ properties. For example, it is not uncommon for one company to completely manage all aspects of another customer’s networks IP allocations, so forth and so on.

And this would create a – this currently can be an entirely transparent process since organization one can create and manage all the resources for organization two.

This would add some burden to that, and while it may be relatively straightforward to create an Org ID, it may adversely impact those that act as a middleware for clients, especially those that are grabbing a bunch of IP blocks and releasing them because of demand scaling up and down. So I have tentative – I have concerns about this.

Paul Andersen: Luckily the person behind you I think has experience in that. So I think he may have some feedback on that.

Owen DeLong: Owen DeLong, independent contractor and member of the ARIN AC. Yeah, I’ve done a lot of the kind of contract work he’s talking about. And I’ve got a lot of clients as well.

And we discussed this actually on the Mailing List. It was pointed out by ARIN staff that, as written, the policy would be implemented such that if you are able to create the Org ID with the proper documentation showing that the Org in question has authorized you to do that on their behalf, you’re fine.

So you’re going to need some form of documentation from your client that says, yeah, this guy’s authorized to interact with ARIN on our behalf, but that should not be hard to obtain if you’re legitimately operating with ARIN on their behalf.

So I think it’s actually a solved problem. I don’t think that there’s a need for changes to the policy text or acrobatics to address it.

Paul Andersen: The LOA returns. Front microphone.

John Sweeting: John Sweeting, ARIN again. As Owen can attest, and anybody else that has created Orgs for other organizations, we have worked with them. It’s the current process. It’s the way we do business today. There’s really no change needed for that or required.

We will verify that the organization has authorized him to do this for them and that he’s able to do it. And if he wants to be put on that record as a POC and they authorize it, he’s put on the record as a POC and manages their record.

Paul Andersen: All right. We still have time in our slot for more speakers. However, we seem to have lost. Would anyone like to make a comment? Otherwise, we’ll close the microphones.

Joe, anyone on the remote typing? Maybe. Closing the microphones in three, two, one. The microphones are closed.

Please thank Andrew Dul, who is running away, for his presentation.

(Applause.)

This is a Recommended Draft Policy, as the former two before it. So we’ll ask now the question of support. Counters in position. Excellent.

Those remote, please indicate whether or not you’re in support of 2018-5 proceeding as written or against. And those in the room, if you are in favor, please raise your hand now nice and high. I know, after lunch, it’s tired. Beach is not far.

Oh, I see a wavering hand in the middle there. Excellent. Thank you. Please lower your hands.

And those that are opposed to the policy as written proceeding, please raise your hand nice and high. Thank you.

As a reminder, if you weren’t able to provide input or didn’t want to come up to the microphone, please find one of your trusty AC members around the event or tonight’s social. Always happy to talk policy, because who wouldn’t?

I’m hearing people mocking me in the audience.

All right. On the matter of 2018-5: Disallow Third-Party Organization Record Creation, the results are: 111 in the room and remote; 37 in favor; one against.

Thank you for this. We’ll move to the next policy.

Draft Policy ARIN 2018-6: Clarify Reassignment Requirements in NRPM 4.2.3.7.1

John Curran: Okay. Thank you very much. We’re going to now consider ARIN 2018-6: Clarify Reassignment Requirements in NRPM 4.2.3.7.1. Alyssa Moore will come up and give the presentation.

This is draft policy, so you’ll see it again before it gets recommended. They’re just refining work, and this is a presentation to help make the policy better.

Alyssa Moore: Hello, everyone. I am Alyssa Moore. My co-shepherd on this one is Alison Wood, world record holder for high jump. So ask her about that.

(Applause.)

So this Policy Proposal is about gaining some clarity around language of reassignments and what would constitute a simple reassignment versus a detailed reassignment.

And if you are new – I notice there are a lot of newcomers in the newcomer session today – I’m going to make this one super easy to follow. So pay attention, and this might be something that you may have some input on.

So we’ve been throwing around these words: assignment, allocation, reassignment and reallocation. But what do those actually mean? It took me a while to figure out when each might be used, and so I’m going to explain that so everyone is on the same page.

So at the beginning of the NRPM there’s this definition section, and it defines what each one of those is.

So an allocation is address space that is delegated by an organization – or to an organization by ARIN that they can then sub-allocate to other organizations. So if you’re an ISP, for example, big ISP and you have downstream customers, you can reallocate address space to them.

Assigned space, if you get an assignment from ARIN, is space that you are to use as the end user. You can’t reassign or reallocate that space; you’re the end user of that space.

So when you make a reallocation, you have to have an allocation in the first place. A reallocation can be further reallocated down the line.

A reassignment is space that is sub-delegated that that organization that it’s delegated to is the end user of.

So assignments and reassignments, that’s the end user. An allocation can be further sub-delegated.

So, the problem I’m seeing with this one is there’s a section in the NRPM that describes when a reassignment might be used – sorry, a simple reassignment might be used versus a detailed reassignment, and there are different informational fields that you have to fill in for each one.

And so what we’re seeing is that there are a lot of organizations who are completing detailed reassignments when a simple reassignment will suffice.

So I’m just going to read through this. So current NRPM section reassignment and reallocation information is being interpreted by some organizations to require a detailed reassignment for all customers. Under the current reassignment schema, only a detailed reassignment or reallocation contains fields for organizational information.

So this policy intends to simplify the reassignment requirements by noting that only a customer’s name is required. So a simple reassignment can be used for most cases.

So here’s the policy statement. I will leave that up for a second, but I’m not going to read through that because I have a better slide coming up that is the redline of this.

So there are a couple of changes that are proposed. So that’s pretty straightforward. We’re just updating it to more generic language. So via a directory services system which meets standards set forth in 3.2 rather than a Whois directory via SWIP.

So a SWIP, S-W-I-P, is a Shared Whois Project. It’s a method of entering information for another organization into the Whois database. So Shared Whois Project. And this is the rest of it.

So it would read as: “Reassignment registrations must include each customer name, except where specifically exempted by this policy.” And then all of the red stuff is new. “Reassignment registrations shall only include Point of Contact information if either requested by the customer or the reassigned block is intended to be routed and announced outside of the provider’s network.”

So two cases where details could be performed. So if it’s specifically requested or if the customer is going to announce outside the upstream provider’s network.

And then finally: “Reallocation registrations must contain the customer’s organization name and appropriate Point of Contact information.”

So that is around reallocations would stay relatively the same.

So this is what it looks like when you go into the back end of ARIN Online to make a reassignment. As you can see there, you can see a simple reassignment or a detailed. For the purposes of this use case, we are selecting a simple reassignment.

And when you go to the next page there, you can see that what’s required of you is just the name of the customer, the Org name and their address. That’s a mailing address or physical address.

So, so far on the PPML, the Public Policy Mailing List, there’s been a little bit of discussion. So one was about the intent of the policy. And they were asking like is this going to eliminate all of these fields when you’re making reassignment. That is not the intent of the policy. It’s just to make it more clear when a detailed versus a simple reassignment is required.

So there were three comments in support, just full support; one comment in complete opposition; and then two comments that were proposed changes. So supported maybe a little bit with proposed changes.

So the comments in support, the crux of that was that a majority of these organizations’ customers with a /29, which is eight addresses, eight IP addresses, or a shorter reassignment would not understand what you’re even contacting them about.

So these are generally smaller, maybe mom-and-pop businesses or Orgs who have an HVAC system or something that requires, for whatever reason, an address of their own. And so they need a net block of some size.

So generally those people aren’t going to be able to respond to emails about abuse or contact about abuse. So that’s why they were in support.

And then the opposition was that the person felt that this further serves to obscure bad actors by getting rid of information that might be useful to track down abuse.

And then the proposed changes. So there was one that said it might be helpful to just adopt the language in Section 6 of the policy manual but with ranges that were analogous for v4 resources.

And there was another proposal to just completely remove the requirements for reassignments and reallocations where the delegating entity, so the organization making the reassignment or reallocation, felt that the customer wasn’t able to be responsible for that block for whatever reason, to just completely get rid of the requirement to reassign or reallocate.

And then there’s another proposed change of a schema that required a name and an email address and a phone number because the mailing address is not a very efficient way to get in touch with someone about potential abuse on their network.

So a couple of questions to maybe kick off the discussion. This is the first time this has been to a meeting. So this is a step toward clarity. Is there support for different contact details of some kind or anything else that you might want to discuss at the mic?

Paul Andersen: Thank you. All right, the microphones are open. This again is a Draft Policy. So two things – my goodness – as they all flood the microphones. Where was that this morning?

There’s two useful things. First of all, any feedback on the policy. But sometimes it’s also useful if we can get feedback: Is the problem statement well defined and a problem you think the AC should be working on, even if you think the solution that they have come up with is valid or otherwise? That is useful feedback at this stage in their deliberations.

And also my apologies to the online stream. I understand that we’re about two minutes lagged. So we will try our best to take that into anticipation as we look for your feedback. But if you could also take that into account; that if you have a question, please get it there early.

As somebody has already done, front microphone.

Joe Provo: Proxy for Jason Schiller, Google, ASO AC. The proposed text just that an ISP is limited as to when they’re allowed to submit a reassign detail such that if the customer does not ask for detailed POC info or intends to multi-home, the ISP cannot submit detailed reassignment.

I would like the language to be reversed to say an ISP must submit a reassignment detailed when either requested by the customer or the reassigned block is intended to be routed and announced outside of the provider’s network.

Assuming this is not intended to limit when detailed SWIPs can be used, I support it.

Paul Andersen: All right, thank you. Comment taken. Next speaker.

Chris Woodfield: Chris Woodfield, Salesforce, ARIN AC. I want to point out one small but potentially significant operational impact of moving, removing most of the contact information from a reassignment.

There are many companies that incorrectly or incorrectly use the mailing address in assignment records for geolocation.

Removing that will lose that – will result in organizations that do that, losing that visibility, leading to less, potentially less, accurate geolocation attempts.

Therefore, I would recommend that if we consider limiting the number of fields required in a reassignment that we not lose the mailing address, keep the mailing address in there, possibly, or make it optional such that the mailing address is not required but is a field that can be added to the record.

I support as written with my recommendation.

Paul Andersen: Thank you for that recommendation in support.

Michael Casadevall: Michael Casadevall, NARALO. I dislike the proposal for several reasons. The first one is the example of the Hivac (phonetic) system that requires a stack IP and only having customer name.

For someone to have a block of routable IP addresses, they need to be responsible for it. And the concept of the customer is not smart enough to manage it, I don’t think that’s a valid argument, because if you’re going to have stack IP space, you need to be able to manage it, or have someone manage it for you on your behalf.

In addition, limiting the amount of information about transfers could both lead to abuse of people’s hoarding IP blocks via shell games and other – the lack of transparency is extremely concerning.

Having more detailed information about how blocks are being assigned to individual customers is very important for dealing with tracking down DDoS, sources, botnets and other information.

So moving – allowing simple transfer, simple reassignment for these sort of things removes clarity into how ISP networks are delegating their networks, and the detailed information should be the standard way to do it, in my personal opinion.

Paul Andersen: I understand you’re against the policy statement, clearly. Are you also against the problem itself being solved?

Michael Casadevall: Personally, I’m not sure I see it as a problem. If anything, I would completely flip this policy on its head and require detailed information for all reallocations except for those that are being directly broadcast and routed by BGP, in which case that organization has the POC and is responsible for that network because they’re doing the announcement on BGP.

Paul Andersen: Thank you. If you would like to speak on this proposal, please approach a mic. We’ll be closing the microphones shortly. And, again, for remote participants, please at least start typing soon so we know.

Steve Wallace: Hi, my name is Steve Wallace. I’m from Indiana University, and I have a question about the proposal. So for a simple reassignment, one of the criteria is the prefix is not announced outside of the upstream provider’s network.

And I think this may be a core case, but it would be interesting for some clarity, there are new services, for example, DDoS scrubbing services –

Paul Andersen: Which services?

Steve Wallace: DDoS scrubbing services. So, in a DDoS scrubbing service, it’s possible that the upstream provider unfortunately might not be aware of a subscriber to a service like that, and there may be a disconnect between the subscriber of the service, the assignee, and the assignor in terms of what’s going on with that prefix.

And so it might be helpful – maybe this is an obvious way of looking at it – but it might be helpful to be more explicit so that that’s kind of a non-traditional way for things to be announced outside of the upstream provider’s block. One possibility is the language is enhanced to directly address that.

In the other cases, it might be an argument that you shouldn’t do this, because those kinds of things can happen. And sort of consistent with the previous comments, someone not understanding that that takes them out of the simple case might be essentially changing the routing situation for the upstream provider.

Paul Andersen: That’s an interesting case. I’m not sure how it would be interpreted, but the AC can take back that feedback. Thank you.

Next speaker.

Kevin Blumberg: Kevin Blumberg, The Wire. I support the proposal. For the first part, which is to change it to name services, directory name services, I would suggest adding the word “valid” or something, or “acceptable” or “accepted.”

The issue is I don’t want to see carrier pigeon over SWIP being used because there’s enough of these services that are turned off where they’re supposed to be turned on, and the people can just invent stuff. So just a suggestion there.

Alyssa Moore: Quick question about that first. So, you don’t think that the language of “that meets the directory services system,” the standard set forth in Section 3.2 is enough? You think that needs to be added?

Kevin Blumberg: I think that your change takes out SWIP and RWhois, which is fine. I agree with that. But allowing people to define themselves what is an acceptable system will lead to it being trolled and abused. Just put “approved” or “accepted” and “generic,” and you’re fine. As long as it’s that, it will be fine.

But otherwise people will just say you need to mail us in to this address in some country that you don’t know, whatever. It’s going to be abused. They don’t like doing it in the first place, and this will just give them the reason to do it.

I want to talk about, more importantly, simple versus detailed. Don’t change the records at all. That is a red herring. It’s a new proposal. Please keep this to the very simple thing of explaining to people when to use a detailed, when to use a simple reassign. It’s a different policy for the other stuff.

I am appalled at the number of detailed reassignments that are in there that have no reason to be in there in the first place. People don’t understand simple reassignments and detailed reassignments, and the reality is anything less than a /24 should not be a detailed reassignment because ultimately that is an unroutable address on the Internet.

So maybe part of it in terms of your requirements should be – and I think you’ll find the vast majority of details that are going in through the API are smaller. They’re /29s and /28s and /27s. They’re useless as detailed.

All they’re doing is giving out personal data about a company, and they are not the abuse contacts that can actually make a difference because it’s not being routed out there. So I think there is more that can be done to improve the text.

The other thing is I don’t – I’m concerned that you are limiting it to only the customer requesting. I have customers who send email en masse legitimately, but I need them to be there. And if they say, no, we don’t want to be there, I don’t want to handle their abuse.

So to say that it must be customer requested, which is – I understand where it was coming from, limits my ability to say you need to do this for very valid reasons, and the only way I’m going to be able to do this is to put it in.

So I would definitely look at that. And there are customers that will request it when they have no valid reason to do it, and it creates work on my side as well. So I would definitely look at that aspect of it. Thank you.

Paul Andersen: Question? Apologize. Please approach a microphone soon. We’re going to be closing the microphone in two speakers. Please move forward.

Joe Provo: I’m actually representing more than one speaker.

Paul Andersen: Physical body at the microphone.

Joe Provo: Myself and some remote participants.

I’d ask to first put the first slide of the redline up. I would disagree with my friend and colleague, Mr. Blumberg, because I do believe that directory service system meets the standard set forth in Section 3.2 as language reviews throughout the NRPM, and I don’t think it has a loophole for allowing carrier pigeon carriage of packages.

But that’s not why I called. Was it intentional to completely remove the Whois reference here and only go with directory services? Because when I read this, this is only – this says these must only be in directory services because we actually struck the Whois element.

Alyssa Moore: I think that was just in keeping with how it’s referenced throughout the rest of the NRPM.

Joe Provo: I think this has an unintended consequence of actually removing the SWIP.

I support in principle and can support as written as long as the RWhois thing is clarified. I’m sure somebody will.

And relaying Anthony De La Cruz: Detailed less than /24 can be needed for abuse. Need to get feedback loop set up that don’t work with simple, in reply to Mr. Blumberg, who noted it is not needed for anyone. And I’m sorry I don’t have his affiliation.

Brian Jones, Virginia Tech: I think I support 2018-6 in principle. Simple is generally better, but do have a fear of not having an appropriate POC for an allocation of addresses.

Jason Schiller, Google: Re: Kevin Blumberg. There may be reasons for smaller than 24 to have a detailed reassignment. The customer may want to handle their own abuse. The customer may want to publish their location information. But generally I do agree with Kevin.

Then: May do publish detailed info simply out of confusion. Let’s clarify when it’s required and when it’s permitted.

That’s that queue. And that also triggered one personal thing. Sorry.

We do know that there are large entities that have automated systems which enter detailed for small allocations because they set them up long before simple existed, and they never changed their systems. That was verified when we interviewed operators for that other POC policy change.

Paul Andersen: Okay, thank you for that feedback. The microphones will close in about a minute. Remote participants especially, please start typing, since I know there’s some lag.

Michael Casadevall: Michael Casadevall, NARALO. I want to add two follow-up points. There’s an interaction between this and the Recommended Policy proposal about third parties creating POCs because in the case of – we’re now dealing with the fact that if there is a detailed proposal, the ISP cannot create the POC on behalf of their client, which may create a problem without setting up the entire authorized paperwork and having the client register with the R1 directly. So those two things may not go nicely with each other, if I understand them all correctly.

Oh, okay –

Paul Andersen: Wait your turn, Owen.

Michael Casadevall: Sorry. And the second train of thought completely derailed.

Paul Andersen: Oh.

Owen DeLong: I was not trying to derail your train of thought.

Michael Casadevall: I’ll get back in line because it might come back.

Paul Andersen: Technically we’re closing this, but I’ll allow you to get your thoughts together, and you can have the last word, barring remote participation.

So microphones are now closed. Front microphone.

Owen DeLong: Owen DeLong, ARIN AC. Yes, it would be good to improve the language in 3.2 to better accommodate Joe’s concern, but as I understand 3.2, I would say that ARIN’s SWIP qualifies as a distributed service, meeting the requirements under 3.2.

So I don’t see it as being a problem, but it would definitely be unclear to somebody that was less versed in NRPM fu than I, and we probably should clean up the language in 3.2 to accommodate that better for a number of reasons, not just this policy.

Paul Andersen: Thank you. Sir, the last word.

Michael Casadevall: Michael Casadevall, NARALO. So the train of thought came back. For allocations smaller than a /24, there are plenty of times where a customer is completely managing those sets of IPs completely independent of their ISP. In fact, I see it fairly common with more technically based organizations.

So I think it is not unreasonable to have a detailed record in there with its own abuse contact, because the ISP is basically just doing the broadcast due to the limitation that we cannot broadcast smaller than 24 without doing horrible things to the Internet Routing tables.

Paul Andersen: Thank you. Any last words? All right. Thank you very much to the AC for the presentation. There’s no poll been requested by the Advisory Council Chair. So this ends this proposal.

If you have further comments or questions, please find your local AC member.

(Applause.)

John Curran: Very good. We are now going to get an update on the ARIN development work, the ARIN website and the ARIN Routing Registry. Richard Jimmerson, come on up. John, are you going to join him? Come on up.

Website and Routing Registry Update

Richard Jimmerson: Hello, everyone. I’m here to give you an update on two of our major projects. Inside the ARIN organization, basically the way we have things structured when it comes to development projects is we really only work on one large project at a time.

Behind that we have some medium and smaller-sized projects we’re working on at the same time, but really only one large project at a time.

One of the projects that we were working on here over the last year and a half was the website and ARIN Online user experience enhancements. I’m going to talk a little bit about that as that project has just been completed.

And we’re going to be starting the next large project space inside ARIN’s development, and that is ARIN Internet Routing Registry. And John’s going to describe that some.

So for the website and ARIN Online, we did complete an overhaul, ARIN.net, on March 2 of this year. Basically the new site is a new, responsive design and an improved user interface.

We put a lot of work into user experience enhancements inside ARIN Online based on feedback that we’ve received over the years through this process, through ACSPs, through customer surveys, feedback that we get from customers on a daily basis over the telephone.

And we did, in fact, focus on web accessibility standards as well, as we do have people contact us who have disabilities that do use our services quite a bit, and we wanted to make sure that the site was accessible for them.

There was a very strong focus on community engagement with this project. We had interactive surveys where you helped us design the navigation, all the way to the way certain elements look on pages, deep down inside the site somewhere.

Also we did in-person and remote user testing. You’ve noticed over the last two or three ARIN meetings we’ve actually had staff members sitting out in the hallways wearing white jackets, doing user testing, walking you through what it is that we’re doing.

And we’ve done site previews over the last year as well for this project. We did complete the project with its deployment on the 2nd of March just here last month. And there are three blog posts that we’ve made this year that you can look at if you want more information about how we actually designed this, we developed this, how we used community input to shape the project, and basically what things look like in the background to get this done.

It was more than just a new face for the ARIN website. It was extensive changes to how we do everything inside ARIN Online to service you as the customer.

And for every one of you in the audience, there’s 100 people not in the room that use the services every week. And we use their feedback in addition to yours.

I would like to thank you on behalf of the staff inside the organization for all of the work that you guys in the room and the people who have attended over the last few meetings have actually put into this project and your participation in this project.

It actually helped us deliver something in response to the needs that you cited to us. And we really enjoyed working on it. And thank you very much for that.

And I’m going to transition over to John Sweeting for the next slide. With our major projects, we have our product owners inside the organization that make sure that community engagement is happening and to make sure that the staff is building what the community asks for.

I was the product owner for the website and ARIN Online changes, and John Sweeting is actually the product owner for the routing registry project that is starting now.

John Sweeting: I’m John Sweeting, product owner of the routing registry. The project is starting now, this quarter. We’re doing – we’re doing and have done a lot of analysis of prior community feedback for the IRR.

We’ve had, I believe, two major consultations over the last three or four years in reference to this project. We’ll be taking all of that input and feedback and creating a project plan, and we’ll be writing stories for this over this next quarter.

Development begins in Q3 2019, although we’ll be doing some development on the routing POC and DNS POC that’s been requested through the ACSP, the ARIN suggestion program.

Those will be – those are starting now. We’re starting on those. We’re writing stories. We’re going to be developing those two POCs during the second quarter where we’re doing all the planning and everything from the rest of the IRR.

The rest of the development, the main development will start in Q3. There’s community engagement throughout the project and plan.

We actually have some volunteers that are external stakeholders in this process. They will be involved every step of the way. They will be invited to meetings. They will be included in our theme party that Deb Martin, in the back there, is putting together.

So we’re not going to go – we’re not going forward blind. We’re going to be very transparent with this and we’re going to share our plans as we go through this. The product will be released in phases throughout, through Q4 2020. There’s probably – not really sure, but there’s probably three, four, possibly five phases that we’ll do deployments and roll off major portions of the new IRR.

Is there any questions? And if anybody – if there’s anybody that feels they would like to be a part of this as an external stakeholder, we do have to keep it limited, but feel free to reach out to me and I’ll talk to you about it and let you know the expectations and everything, see if there’s a fit. And we’ll be more than welcome to help with this.

Kevin Blumberg: Kevin Blumberg, Toronto Internet Exchange. IRR has become very important for Internet exchanges. Getting our members and peers hooked in is crucial, and it’s a huge uphill battle with the current free solutions that are out there, such as ARIN’s, and that’s why this project exists.

Whatever can be done to keep it simple for participants that do not regularly change their data – this system is not helpful for the large organizations that have been doing routing registry data for years.

This system is useful for the people that haven’t been doing it properly or let somebody else do it on their behalf.

So whatever easy system, like easy SWIP and all of that, whatever easy system you can make available to that – and I would hope that you are able to talk to the stakeholders from the IXP communities, I know through MANRS we’re doing a lot of work with this, and this would be a huge assistance to that program as well.

So that was just in terms of support of it. Thank you.

What I don’t see in here is when you plan to have a feature set available for viewing for the community to provide any feedback on. Is that going to occur during this? Because I don’t see that between the project start and the development begins.

John Sweeting: This was just a very high level. That will be done before the development begins. When we come up with here’s the plan, here’s what we’re doing, here’s what we’re going to develop, that will be shared before the development starts.

Kevin Blumberg: Thank you and good luck.

John Sweeting: The community is going to be allowed to have input all the way through this. Most of the community knows me. If they reach out personally or can be an external stakeholder – you know John, you know all – we want the input. We want to do this right. We want to get it right. We’ve got one chance to get it right, and that’s what we intend to do.

Kevin Blumberg: Thank you.

John Sweeting: Anybody else? Okay. Thank you very much.

(Applause.)

John Curran: Round of applause for Richard and John.

(Applause.)

We’re running a wee bit early, and while I want to release you to break, and the Chair has implored me to let you have more breaks, having to do with longer breaks and more breaks because of the beautiful weather and beaches, if I let you out now, there won’t even be refreshments.

So, we’ll take a few minutes and put one little presentation in. It will be Mark Kosters coming up and talking about the current state of RDAP. And once Mark is done, we’ll go to break. Come on up, Mark.

The Current State of RDAP

Mark Kosters: I’m Mark Kosters. I head up engineering. I want to go through a couple of things that are really exciting that’s going on with RDAP.

Who here uses RDAP?

(Laughter.)

Who has gone to the new ARIN search page? You’ve used RDAP.

So, okay, another question. This is a little bit longer in the presentation, but I’ll go through it now. Who goes to the Whois.ARIN.net? Do you like that better than search.ARIN.Net? Go ahead and take a look and tell me what you think.

So, anyway, let’s go ahead and talk about RDAP and what it is.

So basically one of the things that we’ve done – this has been an age-old dream of mine – is Whois is a really, really, really old specification. It’s about as old as the first RFC that came out in 1969, which incidentally I was a little kid then. I didn’t care about the Internet. And many of you probably weren’t born during that time.

So this is a sort of a bootstrap into taking this protocol and actually modernizing it. And this is something that Andy Newton in particular has been working on for a number of years.

Our first foray at ARIN was actually this RESTful service called WHOIS-RWS, which I know many of you have used as well. The next part of this was actually bringing it into the IETF in creating a standard dealing with this. And it supports both domain name registries as well as Internet registries.

Here’s kind of how it kind of looks. You have basically your common data types; status structures dealing with it; object classes, because we like using object-oriented sort of things; and you get your search results. All engineers, all developers really like this new framework.

The old Whois was, okay, I’m going to ask a question, and I hope I get an answer if I do this in this unstructured data format that I need to actually parse. So this is a much better way of actually dealing with this and a more sort of methodical way.

Another thing about Whois is really your client – you may use JWhois, for example, if you’re on a Linux box. And JWhois has a bunch of hints in there saying: Hey, I’m asking for this particular IP address. Where do I go?

And many of you actually come to ARIN first, saying: Hey, I want to know about an IP address in 193/8, which is in RIPE’s region, but you would first come to us, and we would redirect you to RIPE’s Whois server.

Well, Whois is just not that smart. It just goes one certain place and goes on. Or it may have some hints in there saying, well, the com registry is over here, Org registry is over there; I don’t know which server to go to.

With RDAP you don’t have that problem. You use this concept called bootstrapping, where ICANN actually stores who has what, who has these TLDs and who has these IP addresses. And here you can see the concept of, hey, I’m asking for a particular IP address.

It comes back and says, well, ask ARIN about it. You ask ARIN. And it says, well, I actually I gave that space to APNIC, and APNIC is now coming back with the right information. All this stuff is seamless to end users.

So, let’s talk – you’ve seen this; you’ve heard this before. Let’s talk about updates since ARIN 41.

So one of the things that we haven’t been dealing with is flat namespaces like names. And this is something that has been in IETF and has been worked on and is dealing with object tags. And there’s now a way of actually figuring out which registry has the contacts, and you can go ahead and ask them.

There’s also some adopted work that’s going on. One is federated authentication with open ID. This is something that ARIN Engineering has been working on for a period of time as well to have – basically allows you to have more results if you’re authenticated. Right now you’re capped at 256 entries. This way you can get more than that.

You have paging and sorting of results, reverse searches, and under discussion is a jCard replacement. JCard is the specification on dealing with users and how users in their postal addresses are supposed to be.

Different users in different areas of the world have different ways of looking at both names as well as the location where to send their mail. And jCard really doesn’t specify this very well.

It’s something that’s being looked at. It’s actually been exposed within the regional registries in that people want to see the same information no matter which region of the world you’re going to.

There’s some other things going on with RDAP mirroring, so you can actually mirror much like you can with IRR data. You can actually mirror RDAP data at a different registry.

So here’s object tagging. You can see that these particular object tags are known for the regional registries. And here is work that’s going under way with RDAP mirroring, which is something that APNIC is going forward right now.

So RDAP alignment. There’s – the regional registries have been working together making sure that all the things – all our behaviors are very common and very similar.

We had 16 items that we identified at a recent meeting at the IETF where the regional registry technical people got together and said, okay, we have these short-term things that we need to fix, medium term and longer term.

And we met together in Prague, and I’m happy to say that the near-term and the medium-term things we’re actually going to have all done by the end of the year.

Incidentally, ARIN doesn’t have any near-term or medium-term issues to deal with. So the other regional registries have some implementation things that they need to fix.

So another thing that’s going on – going through this fairly fast – is that we’ve added on a bunch of enhancements with RDAP. For example, you can query an AS and see all the associated networks underneath it. And you can also use CIDR searches as well.

We also – as I mentioned before, our new unified search site, which is search.ARIN.net, uses RDAP as its search tool. It’s no longer using Whois.

So that’s interesting because when we were talking about the website update, everything now is based on RESTful services.

So you have this nice GUI on the front side, but on the back side it’s all RESTful, and that includes RDAP. And here you can see a specialized search page that we have for RDAP, so you can actually drill down to particular objects that you want to take a look at. You can actually use this tool much like you can use the advanced search tool on the Whois.ARIN.net site.

And of course for people who like Whois, the old UI is still there. I’m not sure for how long. So this is a time-limited offer. You can go ahead and use the old site for a while at least, but it is there for you to use.

We also created a new documentation for you guys to start discovering this and how to use RDAP. It has a number of cool sort of features that you can actually code against. And what’s really wonderful about this is that you can go across all the regional registries, especially after we got these near-term and medium-term issues taken care of. You can do the same coding on all five regional registries.

So, now, let’s go on and move on to ICANN. So RDAP was a very, very big topic at the most recent ICANN meeting. Why? GDPR.

Has anyone here actually run a domain registry? Okay. Did you turn off all the personal information, or do you still have it available?

Alyssa Moore: (off microphone) We leave it by default private.

Mark Kosters: If you use Whois, before, you can normally go and say, hey, who has ARIN.net. Actually, I’m not sure if this is privacy enhanced or not.

But, like, you’re in my personal domain, for example. There’s no information about it at all. You have to go to the registry – the registrar to find out who has the contact information. It’s no longer used in the general purpose, in the general Internet like it was before.

Before, you could actually go from my personal domain and you can actually see that, hey, I’m a tech and admin contact for my own domain.

That is no longer possible, and the reason for this is GDPR.

And ICANN really, really wants to actually satisfy all the needs of their constituencies, including law enforcements and intellectual property rights people. And they’d like to see some better exposure than they have today.

So this is something that ICANN looked at RDAP and said, hey, with these access control features that it has with the open ID stuff that I mentioned earlier, this could be a really cool way of actually exposing information to authenticated users so you can get some information back without having to go through additional hoops.

So one of the things that ICANN has done is they put it in their contacts that all registries and registrars need to have RDAP implemented in six months. And I believe that’s coming in August if not sooner.

So there’s a lot of work that needs to be done here to make RDAP actually happen, but it’s occurring.

So one of the things that the CEO of ICANN said is I want to create a technical services group that actually deal with RDAP in our community and make this happen.

You can see this group of people here, and you may have noticed that the chief engineer for ARIN is actually in the front. And that’s Andy Newton. He was at ICANN 64 and actually grappling with these issues.

So, again, it’s very much in the forefront. This is really, really big. And I’m excited about it because I’d really like to see Whois go away and actually replaced by RDAP. And ICANN has actually helped put that in place as well.

And here you can see – DNR stands for Domain Name Registries – and you can see since ARIN 41 to 43 that we have a lot more TLDs that are actually serving up RDAP. And so this is great seeing this core protocol, Whois, being replaced by a newer core protocol called RDAP.

So with that, any questions?

Cathy Aronson: Hi. Cathy Aronson. I don’t have a question. I just have a mini speech. No, just kidding.

(Laughter.)

I just wanted to say that I am so excited for you, because almost the entire time I’ve known you, you’ve wanted Whois to go away, and this is just awesome.

Mark Kosters: Yeah, thank you. Thank you. So just a little forefront, who here uses RWhois?

Unidentified Speaker: Retired it.

Mark Kosters: Great. So I helped create RWhois as a replacement to Whois, but it didn’t make it. This one I hope one will. In fact, it will. So, I’m excited about RWhois going away as well, even though it’s one of my babies.

Joe Provo: Jason Schiller, Google: Do we have full one-to-one support for all of the existing Whois flags – query by record type, network ASN, POC or customer, query by attribute, domain and handle name, disable flags, dot, dot, dot, dot, dot?

Mark Kosters: I believe a good number of them are there, if not all of them. Admittedly, Whois-RWS actually has some more features than RDAP does, because RDAP is actually a standardized protocol, whereas WHOIS-RWS has more things that you can actually do – queries, hey, show me all the prefixes shorter than this length, that sort of thing. That’s not in RDAP. But most of the major queries are there.

Joe Provo: He’s still typing.

Mark Kosters: Is this Jason?

Joe Provo: Yeah. I’ll come back.

Michael Casadevall: Michael Casadevall, NARALO. I have a technical question. What prevents man-in-the-middle from the bootstrap servers to the end registries in case of state-sponsored censorship or similar use cases? Is there cryptography keys or something to the KSK?

Mark Kosters: So there’s – all this is done over https transport, so they need to have a cert associated with that that’s validated.

Michael Casadevall: Okay, thank you.

Mark Kosters: You’re welcome.

John Curran: We’re going to close the mics shortly, so if you have a question, remote, or at present, please get to the mics.

Joe Provo: Jason Schiller, Google: Can we make sure we have full one-to-one support and how to manufacture the queries prior to killing Whois?

Mark Kosters: That’s certainly a very valid request.

Joe Provo: Thank you.

John Curran: Go ahead, Andrew. You’re the last.

Andrew Dul: Andrew Dul. I just noticed that there are differences in being able to sub-string search by – sub-string search on, like, name records. I haven’t figured out how to do it in RDAP yet. Maybe that’s my issue.

But if you just want to throw a sub-string search in for a part of a company name, doesn’t always seem to return the same things between Reg-RWS and RDAP.

Mark Kosters: Yeah, so maybe we can sit together and go through some of this a little bit later. All right.

John Curran: Thank you, Mark.

Mark Kosters: You’re welcome.

(Applause.)

John Curran: So I said you guys were going to get a break, but I lied. So I’m going to bring Richard up. The Chair has asked to reorder things because it will provide potentially more free time at the end of the day.

So we’re pulling a presentation up from the end of the day while we get towards the break. So this will be the last presentation before the break, for real this time, and it will be Richard Jimmerson.

He’s going to talk about ARIN meeting agendas, like the meeting we’re having and the agenda we’re having and how we’re rearranging and where we decide what goes on in the meetings. Go ahead, Richard.

Community Input into Future Meeting Agendas

Richard Jimmerson: Thank you, John. If you think I’ve been up at the microphone too many times today, then this presentation is for you.

So, from ARIN 1 in the late 1990s all the way through ARIN 44, which is the October meeting coming up later this year, the agendas have been set by the ARIN staff organization.

Basically, what we’ve done is we’ve looked at all the policy discussions that are active inside the process. We’ve given prioritization to those on the agenda. And we’ve basically filled in the holes everywhere else as the staff.

Occasionally we would reach out to the Board and the AC for items that were of interest to them, and occasionally things would come up on the Mailing List or in other places that would dictate things that we did put on to the agenda. But basically, it was driven by – it has been driven by ARIN staff.

What we’re proposing is, starting with ARIN 45, which is the Louisville meeting next year in April, we want to change that. So at the beginning of the year, we would like to change – after the October meeting this year, we’d like to change how agendas are created for these meetings.

And the way that we would like to change it is by removing the staff organization from being the group that decides what’s on the agenda. So, what we envision – and we’ll have more discussion about this throughout this year – is that we would do an open call for content submissions and suggestions, much like we did back in the first few ARIN meetings where John Curran or Kim Hubbard would send an email to PPML and say: The meeting is in a month; what would you like to be on the agenda?

The agendas would be set by a program committee instead of the ARIN staff organization. That committee could include community volunteers, elected AC members, and ARIN staff would be there for support to that committee as part of the committee.

All agenda items would be vetted before the hotel rate cut-off. Basically, what we’re saying there is there would be a timing requirement on when we would have to have the agenda set based on decisions that we had to make with the hotel and our contract and those types of things. And it also allows people to arrange travel who might be speakers.

And open agenda space would be filled as available by this program committee, but the policy discussions themselves would continue to take precedence.

It’s very important that all of the policy discussions be on the agenda and that they be spaced appropriately, giving the appropriate amount of time, and they be basically set in stone so that remote participants would be able to tune in reliably when those are on the agenda and be able to participate without being in person.

The potential benefits to making this change is the community involvement would improve transparency in the agenda creation. A lot of people have wondered in the past, perhaps, how do you create the agenda, why is this on the agenda, why isn’t this other thing there.

And of course, it’s come up in our surveys that we did with the community for customer satisfaction. The way that we create the meeting agendas was rated one of the lowest items of something that they thought we were doing good or bad.

New content opportunities, community member studies and outcomes could come in. We could have technical case studies for DNSSEC and RPKI, community-led panels on registry-related topics.

And we expected it would promote wider participation and attendance for future ARIN meetings in the Policy Development Process, because if you’re involved in actually creating the agenda yourselves, your peers may be more interested in coming to this meeting than they are today as it’s created by staff.

So, questions to the community. If there’s a discussion here, these are the types of things we’d be interested in starting with. Of course, there’s more time to discuss this in the coming months, but does the proposed approach work? Are there any topics you’d like to see that we don’t cover now? Is there another desired approach you’d like us to take with agenda setting?

John Curran: Questions. The microphones are open.

Kevin Blumberg: Kevin Blumberg, just myself. I was on the NANOG program committee, a group of volunteers who did exactly that.

This is not going to work for ARIN. There are too many things that are mainstays that have to stay.

And my bigger question is: What is left that is optional? There are some updates that we can take. You used them as filler, et cetera, because you don’t know how many policy things are going on. But I can’t have – I’m talking about me – I can’t have you take away the Staff Experience Report because five people in a room decided it’s not that important. I can’t come to this meeting without some critical key things.

So how much time is actually left that we can program around? Do you want to add a day before to do some technical things? Is that part of this? I’m trying to understand where you’re going with it, I guess.

John Curran: So there’s approximately an hour a day that is based on the average AC workload and what we have to report. There’s still about an hour a day. In fact, there could be two if we squeezed the breaks down and had you guys really work hard. But let’s say there’s only one because we’re not going to be mean.

So, we do presently open up the meeting to select presentations. We’re going to see one shortly on economic factors and IPv6 deployment. There’s one tomorrow on the UPENN study on RPKI.

Right now, the decision-making for what that is, is somewhat ad hoc. It’s completely opaque to you folks. It involves me and the team and what the staff brings to me that waits, to the point where I go, okay, let’s put that on the agenda, you get on the agenda.

Now, if you’re saying you love the agendas and you love the job I’m doing, that’s great. But the reality is that we don’t have a call for presentations right now. There could be more good content that people want to see, and there could be more presentations like the ones we’re going to see today and tomorrow.

But for those one or two hours that we do have, not taking away from the things that you must have to get your job done, but for the slack in the agenda, the question is: Do you want a program committee and do you want to call for presentations in case someone has something useful they want to present to the ARIN community?

Kevin Blumberg: Thank you. Please define what is not on the table for this discussion. The one or two hours, that’s great. But I noticed, John, that on this call you had 15 minutes for open mic, where we used to have an hour or 30 minutes, or whatever. And maybe it’s because people just aren’t interested in doing open mic, but some of the things have really changed.

John Curran: Let me turn it around. What is not on the table, Kevin? What do you not want to be on the table? What is required? Obviously the policy presentations that are specified in our RDP. Obviously there are reports, like the Policy Experience Report, the Number Status Report, and there are certain staff reports.

So, beyond that, do you need to know that, no matter what, we’re going to have an hour for open mic?

Kevin Blumberg: No, open mic was an example where I noticed a change. The question becomes do we need the global updates, because that is two hours. And for me, personally, I would like to see the global updates. I believe they’re an important part of being part of the RIR system. But that’s a huge chunk that could be, well, do we need it for everybody.

I would like to see what’s, like I said, on the table and off the table. If you’ve got an extra hour, great. I think having a small group of people that can vet stuff, wonderful for that hour, you know?

But to me there isn’t a huge amount of time – this isn’t programming the whole thing, it’s just a small amount.

John Curran: Understood.

Cathy Aronson: He was up first.

Peter Thimmesch: Peter Thimmesch with Addrex. We’re completely in favor of this because it does enable different discussions and people to come in.

I think a combination of what Kevin’s concerned about, which is a set set of things that are always in all meetings, it’s just basically root, but having an outside program committee of people that are established and able to bring in people will bring other people involved, it will get a larger attendance, it will get more information that are core and relevant to members and to community.

So I can’t see how that’s a bad thing as long as you do keep your set structural things that you always have at meetings, which seems to be repeated in all of them. And I think it’s actually a good thing.

Cathy Aronson: I’m Cathy Aronson. I just had a question. So what about the fall meeting? Because it’s really abbreviated compared to the spring meeting and done in conjunction with NANOG. Is that going to change somehow? Because there’s not usually extra time in that agenda.

John Curran: We would usually restrict the fall meeting to a very small number of external presentations, like a slot or two of 20 minutes, 30 minutes tops. We really don’t have a lot of slack in the fall. We have far more flexibility in the spring.

Richard Jimmerson: And as an interesting aside, it’s the reason why we’re proposing we start this in the spring of next year instead of the fall of this year.

John Curran: We don’t have to do this if no one’s excited by it. I can use my crystal ball. I haven’t failed so far, I don’t think. But openness is good.

Paul Andersen: I’ve also been getting more, the same way, John. I’ll get people who have approached me saying “I’ve got a great paper” or “Would the Board consider letting this get presented?”

And we don’t have a good process for that. That’s why we thought – I don’t see it as so much just the entire agenda as being thrown over, but is there a better way that the community can help us figure out what is interesting content to augment the other very exciting policy and ARIN administration presentations that I think would continue to be there in some form.

Joe Provo: Brian Jones, Virginia Tech. Just a suggestion. There could be a public section during ARIN 44 for developing a backlog of agenda items which could be prioritized and voted on as additional items to the policy discussion and mandatory reports.

Richard Jimmerson: Thank you.

John Curran: Back microphone.

Alyssa Moore: Alyssa Moore, Canadian Internet Registry Authority. I would support something like this for whatever the hours of slack time, half an hour of slack time, to be able to have the community decide do we want to see a presentation about the economics of IPv6 or outside studies of RPKI.

I would like the opportunity to engage and have choice of a call for presentation, so I support it.

John Curran: Microphones are closed – front mic.

David Farmer: David Farmer, University of Minnesota, ARIN AC. I like this idea. My suggestion is let’s try it for a couple of years. Don’t say that this is the way it’s going to be forever yet until we know we like it. That’s it.

John Curran: Okay. Understood. I just managed to mutter the words “Microphones are closed” and you then got up, Chris. Chris, can I help you? What do you have?

Chris Tacit: I just wanted to say that I think this is a great idea.

John Curran: Wonderful. John, did you need to comment?

John Sweeting: I needed to answer – so there was a question on initial requests. So, I got reading on initial requests since January 2017. We’ve had 328. It’s about half and half end user and ISP. End user is limited – it’s justified a /24 without justification, and ISPs are approved /21 without justification for that.

Under 4.10, there’s 16,384 in the pool, of which 536 have been used. So there’s 15,848 /24s still available.

And on MDN, since it was approved, we’ve had 282 requests. So that’s like 2.8 percent of all requests for IPv4. Once the 24-month rule went into effect, we’re down to – it’s .1 percent of the requests; we’ve had like two. And the average sites in those requests were between five and seven.

John Curran: Okay. Thank you.

We’ll let John clean his work queue. Very nice. Any other questions for Richard? Anything remote? Round of applause. Thank you, Richard.

(Applause.)

Okay. I said I’m going to give you a break but – no, I’m actually going to give you a break this time. Wouldn’t do that twice. That would be cruel.

Okay. So, folks, we’ll have a break outside. There’s refreshments. We’ll come back at 3:30, promptly.

We’re going to handle ARIN 2019-1 on clarifying IPv4, and ARIN 2019-3. So we’re now broke. Come back at 3:30 promptly. Thank you.

(Break from 2:56 PM to 3:29 PM.)

Draft Policy ARIN-2019-1: Clarify Section 4 IPv4 Request Requirements

John Curran: If the people will come in, we’ll get started. Hopefully everyone had a wonderful break. We have two more policies to get through, and the first policy is ARIN 2019-1: Clarify IPv4 Section 4 IPv4 Request Requirements.

This is a Draft Policy, and as such there is no staff introduction. It is not going to be potentially sent to the Board after this meeting. It’s going to definitely come back to you. But the AC would like to present and get some input, so I’ll invite Kat Hunter up to give the presentation. Come on up.

(Applause.)

Kat Hunter: Good morning. I’m Kathleen Hunter. I go by Kat. This is Draft Policy 2019-1. Myself and Amy Potter are the shepherds on this policy.

So the full problem statement is up there. I’m not going to bore you with the entire thing, but in January there was a face-to-face meeting where the Policy Experience Report was discussed with the members of the Advisory Council.

ARIN staff has observed a pattern where the organization – where an organization transfers space under 8.2, which is mergers and acquisitions, to a specified recipient and immediately applies for space on the waiting list after that, the activity appears to be speculative in nature and not consistent with sound address management policy.

So the policy goals, there’s two here: Clarify the waiting period to only prohibit requests for IPv4 allocations under Section 4 of the NRPM; and disallow organizations that have transferred space to other parties within the past 12 months from applying for additional IPv4 space under NRPM Section 4.

So this is the current policy as written. Repeated requests in a manner that would circumvent 4.1.6 are not allowed. An organization may only receive one allocation assignment or transfer every three months.

So in bold is where that’s actually going to change. An organization may not apply for IPv4 address resources under the section if they have received an allocation assignment or transfer of IPv4 resources less than three months prior or the organization has transferred space to another party under Section 8 less than 12 months prior. So if you’ve transferred space out, you have to wait 12 months.

PPML reception has been generally positive. So most of the discussion was to keep the two topics, the two goals together. This should curb bad practice, and anything that clarifies Section 4 is welcome.

So some discussion points. These policy goals are severable if the community prefers to address them independently.

There are a lot of other discussions that are ongoing about future policy changes for the waitlist. Do you believe this policy is worth pursuing as a potential stopgap for bad behavior, knowing that larger policy discussions are going on?

Something I didn’t list on here but was brought up a couple times in the last day or so, is 12 months enough time? Would you rather see that number go to 24 months? Is it too long? Too short?

And that’s it.

Paul Andersen: The microphones are open. This is Draft Policy, so we’re looking either for feedback on your support or not for the policy statement or the problem statement. So, please approach a microphone. And rear microphone, please.

Kevin Blumberg: Kevin Blumberg, The Wire. I support the policy. In regards to the 12 months, I believe if a staff member or somebody from the APNIC region could comment, I believe that their latest policy had a five-year restriction, and if somebody wants to just clarify that.

I think that that’s probably too long because this is dealing with a number of things. But I don’t know if 12 months – excuse me, I don’t believe 12 months really curbs anything.

What we’ve seen with other things is people are willing to wait. So I would probably look and be very – I would personally be okay with 36 months. And looking at something like that, you could obviously poll the list of people, but I don’t think that 12 months is enough time. The rest of it, absolutely this is a good cleanup. Thank you.

Paul Andersen: Thank you. Others that wish to speak in favor or against the concept, policy, suggestions, questions? Rear microphone.

Tony Smith: Tony Smith from APNIC. Just to clarify the comment, prop-116 passed in our region, I believe it was 2017. It was related to our final /8. The Policy Proposal initially asked for all transfers from the last /8 block to be banned. That then changed to a two-year period. And then from the final consensus call it changed to five years, and that’s what passed as policy. So, that’s for our final /8 block.

Paul Andersen: Thank you for the clarification.

Rear microphone.

Chris Woodfield: Chris Woodfield, Salesforce, ARIN AC. I initially submitted this proposal. I obviously support it as written.

Paul Andersen: You never know with this crowd. It’s good to clarify.

Chris Woodfield: But I’m absolutely perfectly happy with longer time periods that have been proposed. 12 months was an initial stab. Seems like the community is coalescing on something longer than that. And I’m perfectly okay with that.

Paul Andersen: Okay. Thank you. Other comments? For those that are new, The esteemed AC locks themselves in a room and tries to take all this input and decide what to do with this policy. And the input they get right here is really important to that. It’s great if you can come up and speak into a microphone.

We’ll close the microphones soon if nobody comes. Please approach a microphone quickly. I see a remote participant back and forth. I think he’s still getting it. So why don’t you go ahead.

Michael Casadevall: Michael Casadevall, NARALO. I’m supportive of this because an organization that requests an IP block and then transfers it out immediately is either gaming the system or basically shot themselves in the foot, they didn’t need the block in the first place.

So I’m looking at this as a way to drastically reduce abuse of Section 4 and requesting IP blocks.

I actually feel like 12 months is too short, and I would be much happier with a longer period with an exemption that if the – that if the party that received the block can document why circumstances changed, they can then have that waivered on a case-by-case basis.

But I feel like a strong line against gaming and hoarding blocks is very much the way to go, given IPv4 exhaustion.

Paul Andersen: Thank you for that.

Again, I urge you to approach. We’ll be closing the microphones after the remote participation if we don’t see someone moving to a mic.

Joe Provo: I’m proxying multiple remote participants and also have my own two cents.

Jason Schiller, Google, ASO AC: I support the proposal with a restriction of 12, 36 or even 60 months, but it should not apply to M&A activity.

Next, Andrew Gallo, GW: I would suggest a longer time, 36, 48, 60 months.

Brian Jones, Virginia Tech: I support Draft Policy 2019-1. I would also support if the waiting period were extended to 24 months or longer. I like the idea of addressing both issues for requests and transfers in the same section.

Paul Andersen: Thank you very much. And you had your own.

Joe Provo: My comment was: Longer, please.

Paul Andersen: Lots of feedback on the length. Great to have. Front microphone.

Rudi Daniel: Rudi Daniel, ARIN Fellow. I’m in support of the policy. I’m also in support of the longer time period. Certainly more than 12 months.

But I think there should be some safeguard built into that, because supposing someone – the conditions change, if there was a 36-month period and the conditions changed within that period, then there should be some let-out clause.

Paul Andersen: Okay. Thank you. We’ll keep the microphones open because the flow is going. We have the time. We’re not trying to cut it short. We don’t want to sit with too much dead air.

Rear microphone.

Chris Woodfield: Chris Woodfield, Salesforce, ARIN AC. I wanted to address the last comment that there’s current language in that section – I’ll read it out loud.

Actually, it’s on slide 4, I believe, if you want to go back to that.

Yes, the final sentence there that starts with “ARIN at its sole discretion,” that is that let-out clause that you’re referring to, I believe.

Paul Andersen: Lots of time on the discussion and the – any feedback?

Michael Casadevall: Michael Casadevall, NARALO. Just bringing up on the policy of the sole discretion.

That may be a little bit too vague. It may be better to have a strong set of guidelines that go into what a waiver involves so the process is consistent, just based off my experiences on how various waivers have worked in ICANN in the past.

Paul Andersen: Thank you for the input. Again, I’m now going to close the microphones after this comment. So please come to the microphone if you would like to make a comment, or start typing.

Rear microphone.

Kevin Blumberg: Kevin Blumberg, The Wire. The last part related to the waiver. I would like to ask the staff in front, would an M&A be considered a change in circumstances that would allow for it? Because that sort of addresses Jason’s concern from earlier.

And I don’t have a problem with the ambiguity there, because I think the reason for that ambiguity is to prevent gaming that we’ve seen in other ways.

So while I would love – I know that having specificity is wonderful. I believe that that sole discretion was put there because if you start documenting it all, it’s just an abuse vector.

So I guess to my first question, which is the most important, would an M&A be considered a change in circumstances that would then be used?

John Curran: We evaluate M&A on a case-by-case basis. It’s not the M&A. The M&A itself, you can take two entities that are operating with address space and functions, and you combine them. And the functions remain and the address space remains, then the combination doesn’t create in and of itself any change in overall circumstances. Okay? So an M&A would not necessarily trigger.

You have an M&A where you’re divesting units and businesses are going there and addresses are going here, yes, you may have a circumstance that on a case-by-case basis we need to accommodate. Depends on the particular of the M&A.

Paul Andersen: Microphones now closed. Can you flush our queue?

Joe Provo: I realized when I made my personal comment I did not drop my affiliation. Joe Provo, Google, ARIN AC. Support in spirit and longer, please. But we’ve got to do something. So yay.

Remote participation: Jason Schiller, Google, ASO AC: An address holder that finds they’re holding unneeded IP space could always return it to ARIN or another RIR or IANA as applicable with no penalty, right?

That’s it.

Paul Andersen: Thank you. That closes the discussion. Thank you very much. Kat, as this is your first presentation, you win these lovely glasses, if you need them.

(Applause.)

Thank you for your presentation.

Draft Policy ARIN-2019-3: Update 4.10 – IPv6 Deployment Block

John Curran: We’ll continue the policy block with the last policy of the day, and this is Draft Policy 2019-3: Update the 4.10 IPv6 Deployment Block Requirements.

Alicia, come on up.

Alicia Trotman: This policy, myself and Owen are the shepherds.

Let me give you a little background. This is the problem statement. There’s an implementation issue with the current text as written, as well the 4.1 as currently written a /28 is the minimum. However, ARIN allocates /22 as its minimum size.

The current RPKI landscape is also an impediment to using this block size. As well, the /28 is pretty much unroutable practically on the Internet, which leads to requiring a solution for this.

This is the updated text. Let me put some of the changes in perspective for you. The first change to the paragraph – this is pretty much editorial. It doesn’t change the meaning of it. It was just a swap of a couple of words. And I will move to the next change.

This is where we get on to the meat of the matter. So the current text, it states that the block size would be subject to a minimum of a /28 and a maximum of a /24. ARIN should use sparse allocation when possible within this /10 block. The author would like – the block will be subject to a minimum and a maximum allocation of a /24. ARIN should use sparse allocation when possible within this /10 block.

Second change – this is in the conditions – this is Condition No. 1. Currently it states “The applicant may have received resources under the policy in the preceding six months.” The author would like it changed to “The applicant may have received resources under the policy the preceding six months and cannot receive more than a /21 under the policy section.

Condition No. 3 has also been altered. It currently says “Previous allocations/assignments under the policy must meet the utilization requirements of the end user assignments.”

The author would like “Previous allocation/assignments under this policy must be utilized to at least 80 percent to obtain an additional allocation or assignment.”

They brought the end user requirements to 80 percent into this policy so that it would stand alone, 4.1 would stand alone by itself and doesn’t reference the user assignments.

Condition No. 5 that is currently in the text has been completely removed.

So a summary. There’s been major changes that have been made. Raise the minimum size to a /24 and limit the amount an organization can receive to a /21.

Secondly, removes this – the new text removes the requirement for the return and renumbering.

Thirdly, clarify the utilization requirements by placing them directly into 4.10 rather than referencing the utilization requirements of the end users.

And that is it. Any questions?

(Applause.)

Paul Andersen: The microphones are open on this, our last policy. Come one, come all. Come to the microphone. Front microphone, please.

Michael Casadevall: Michael Casadevall, NARALO. I’ve got multiple comments to make on this. So while it is not practical to route a /28 in and of itself, it would be possible – we encounter this problem on 44NAT. For those who are not aware, that’s the ham radio, 44 /8.

And how we handle this is that we group blocks smaller than /24 together within a region so they can all be routed from a single endpoint so multiple customers can handle that.

So the practicality of having an allocation smaller than a /24 is not necessarily a bad thing because it prevents customers from having more IP space than they need and may be possible to solve via mechanism of aggregation.

Secondly, in reverse DNSSEC terms, it is possible, although, granted, uncommon, to actually subdelegate right down to the individual IPs via NS delegations from the third level of the reverse lookup zone.

So it is possible, granted painful, that a customer could manage the reverse DNS by simply having NS records for each individual IP address within their block.

This would make lookups a little bit slower in practice but it would be possible if not exactly practical.

Finally, I am somewhat concerned on having a higher minimum. I already addressed that. I think those are my points.

Paul Andersen: Thank you for that. I think the comment on the block, at least as I read it, was not so much that it’s not technically possible to do the DNS, it’s just the tools and back-end systems would require significant upgrade.

Front microphone.

David Farmer: David Farmer, University of Minnesota, ARIN AC. The /28 was when we were going into runout was the idea that maybe we were going to change what was routable. That did not occur. Let’s just move it to the /24. I support the policy as written. Thank you.

Paul Andersen: Thank you. Microphone here on the side.

Kevin Blumberg: Kevin Blumberg, The Wire. I support the policy. I want to bring up a couple comments. The first is I already authored the exact same thing three or four years ago to change it to a /24 and that was abandoned for a very, very good reason.

It was abandoned at the time because people said legitimately there are use cases where we don’t need it routable; we need unique identifiers for OSPF or for whatever it may be. We don’t need it and there’s no reason to do it.

The reality is that most of the space that’s going out does need to be routable. But what I would suggest with the draft text is allow smaller blocks when the person requests it but default to a /24 from a staff perspective.

So if there are people that need a /28 to handle their internal routing – their internal router IDs for BGP or OSPF, whatever the case may be, and they’re happy with that, I don’t think it will be used. But that was the concern back then.

The default if it’s going to be routable it does need to be /24. And all of the statistics have shown that.

The second thing is I don’t like the /21. When we’ve been talking about all sorts of other areas a /22. I would like to understand why /21 was chosen where we’re choosing /22 as sort of the maximum allocation size for other things. I would be more comfortable keeping it consistent of a /22. But overall I 100 percent support this.

Paul Andersen: A comment why /21 was picked?

Andrew, do you want to line jump for a second?

Andrew Dul: So /21 was picked because I thought /22 was too small. This is not an aggregatable block because all the /24s will be sparsely allocated. There’s no aggregation in here. It’s separate /24s up to a /21.

Paul Andersen: Thank you for that. Kevin, does that address your question, maybe not change your position?

Kevin Blumberg: This is a finite, very small pool. 16,000 is not a great amount. It’s meant to kick-start. So I still believe that a /22 based on everything else is probably more appropriate. And that would be my suggestion.

Paul Andersen: Okay. Thank you for that. Please approach the microphones because the microphones will be closing if we don’t have a queue to fill. Front microphone.

Joe Provo: Remote participant proxies.

Jason Schiller, Google, ASO AC: I’m confused about what problem 2019-3 is trying to solve. If a customer asks for a /28 of v4 in support of v6 transition, can ARIN not give them a /28?

Upon ARIN giving them a /28 and noting that rDNS and RPKI won’t work, can’t the customer still take the /28 if they need it only for BGP router IDs and thus don’t need it to be widely routed or RPKIed or have working rDNS. And if a customer says, “oh, not rDNS, can I have a /24 then?” Can’t ARIN give them a /24?

Paul Andersen: Repeat the last question again.

Joe Provo: Should they receive the /28 and then say, “oh, gosh, it needs to be a /24,” can’t ARIN give them a /24?

John Curran: Justification for /24 is significant compared to them getting a /28. We don’t issue /28s right now.

I’m not sure – unless you guys make some radical changes, I’m not sure we ever would. The question lacks real-word context to me, I guess. Are you proposing issuing less than /24s? Smaller sizes?

Joe Provo: /28 is covered under the policy that’s trying to be changed.

John Curran: I’m sorry. I guess what I’m trying to say is if someone came and got a /28 and then they wanted to come back and get a /24 instead, if there’s enough space available and we allocated the /24 in a sparse manner, we could do that. I’m not sure we’re going to have the space to do that.

So the answer would be no, I expect.

Andrew?

Paul Andersen: Can Andrew line hop for a second again?

Andrew Dul: So this is the use case as I understood it. If you ask for a /28 for location A and receive a /28 for location A, knowing the caveats around routability, RPKI and whatever, and then what ARIN does in the database is actually issue you a /24 because it can’t issue you a /28.

Then when you come back and say, hey, I need another /28 for location B, six months later or longer, ARIN says, well, you don’t qualify because you haven’t filled up your /24 yet.

That’s the use case that we’re trying to squash with this policy, amongst others, if I understand –

John Curran: Every time we do that we need to administer DNS which turns out to be an adventure.

Go ahead, John.

John Sweeting: Basically they would argue later and say we did not ask you for that /24; we only asked you for that /28. Now we’re asking you for another /28 because we can’t use the rest of that /24 based on what we asked for and how we’re using it.

John Curran: Right. I don’t think our internal reservation of a nibble of space, a /24, because someone’s asked for /28 on a nibble boundary, the fact that we have to do something bigger does not mean that we need to recognize that you need to fill our internal database allocation.

So if you’ve got a /28 and you’re entitled to get another /28 because you used the first one, I would imagine we’d work to implement that so that’s not a problem.

The fact that we might allocate that out of a /24 and not put anyone else in it for our own reasons should be an implementation issue, not a policy constraint on someone requesting more space. If it is a policy constraint on someone requesting more space, I’ll fix it.

Paul Andersen: Andrew.

Andrew Dul: That’s the use case that was described to us at the Policy Experience Report in January that prompted this policy. Unless I misunderstood how you’re planning to fix it, then –

John Curran: Presently we do allocate – we have to allocate things on /24 boundaries because, amongst other things, reverse DNS requires it. Okay.

I’m not sure – I guess the question that comes up is you’re saying – what I’m lost about in this use case is whether or not we’ve had someone actually come back and do that request.

Paul Andersen: Yes.

John Curran: And they were turned down because we had a /24 allocated to them and they couldn’t get a second /28 from within the /24 because they thought they only had the /28, even though we allocated a /24.

Andrew Dul: But then –

John Curran: Right. I see the problem. If you take that into consideration, then they have all the /28s in that /24 and we gave them a second one, because they asked for a second one.

But the policy doesn’t clearly support it. Okay. So we know what we all want to do here. We don’t want to have them qualify according to a /24. We want them to be able to get the second /28 in the block of /24 we already put aside without them justifying against a /24. Right?

Paul Andersen: This seemed so much easier 10 minutes ago.

John Curran: Is that the goal of what you’re trying to solve?

Andrew Dul: I think we’re trying to solve multiple things here. This was prompted by the use case that we discussed, and I tried to illuminate here maybe incorrectly, but as I understood it.

But I think the other issue we’re trying to solve with this policy change is actually moving the boundaries so that we have – give people routable blocks to avoid the confusion of you gave me this /28, I can’t use it. Now I need a /24, to just cut that whole process out and give people /24s.

I’m sensitive to Kevin’s comments about, well, people might only need a /28 for their OSPF router IDs. And, honestly, I don’t care if we give them 255 instead of 16. That’s fine with me.

The people who want to ask for OSPF router IDs that really need them, they can have 255, because I think there’s not very many people are going to do that.

John Curran: Based on the Policy Experience Report, we have a working way forward that we’ve done but it’s not reflected in policy. So you can adjust the policy and that would be a good thing. It’s not a crisis one way or the other.

Paul Andersen: But luckily we have 2019-3 that proposes to fix this. It’s a miracle. Can we get some semblance of a line here. You’ve become the mic huddle.

Joe Provo: We’re nesting too deep.

Clarification from Mr. Schiller. Then there’s another remote participant.

Jason Schiller, Google, ARIN ASO AC: My read of 4.10 says if I get one unit of 4.10 resources and want another unit, then I may need to renumber.

So bumping up to a /24 may mean renumbering. Renumbering is not a reason not to give out /28s. My use case is I asked for a /28. I made a mistake. Can I give back my /28 and get a /24 with the justification I used for the first /28 which is bootstrapping IPv6?

I don’t want to cut out the process, but want to clarify that it’s easy to trade up from a /28 to a /24 if they’re willing to renumber.

Paul Andersen: Question for John Sweeting?

Joe Provo: Just clarification of that interpretation of 4.10.

Paul Andersen: Why don’t you show him the question and he can give you clarification. Go to the next microphone.

Owen DeLong: Owen DeLong, ARIN AC, policy shepherd. I support the policy as written. It was kind of silly when we put the /28 in in the first place. But it looked like things may go in a way that would make that desirable, especially when people were pushing us down from the /8 that we wanted to reserve for this to a /10. So we did what made sense at the time. It no longer makes sense.

Moving to /24 is goodness. More importantly, I think the /21 cap on recurrent issuance is a good thing. And I’d like to see that implemented in the policy. So, yeah.

Paul Andersen: We’ll let John Sweeting jump in here.

John Sweeting: John Sweeting, clarification. We’ve been talking about giving out /28s. We cannot give out /28s by policy. Our minimum assignment size is a /24. That’s the problem.

Correct. If they asked for a /28, we give them a /24 because we have to by policy.

Unidentified Speaker: By implementation, not by policy. The policy says you give out /28s.

John Sweeting: I believe it’s policy that says minimum allocation or assignment is /24.

Paul Andersen: All right. We’re going to switch to the NRPM.

Next microphone, please.

Andrew Dul: Andrew Dul, policy author, ARIN AC. I support this draft as written now. I would also support the removal of the six-month requirement in lieu of the changes to hook this to multiple discrete networks as we discussed earlier today, which would allow practically an organization to get eight of these at one time at the beginning sparsely allocated.

That seems okay to me. I’m okay if we leave the time restriction in. The reason we have /21 is it’s eight distinct /24s.

I thought four was too small. And the statistics that John Sweeting provided us earlier about the number of multiple discrete networks within an average multiple discrete network larger organization of – I think he said it was seven, fits very nicely with the eight number of a /24, /21 of eight /24s.

Paul Andersen: Okay. Thank you for that. I guess assuming that we’re referring, of course, to either 4.3.2 or 4.2.1.5, that would say that the minimum assignment by policy is a /24, I think that’s what John Sweeting was referring to.

John Curran has a point.

John Curran: If I could speak. Sorry, I missed earlier someone was referencing 4.10, the IPv6 deployment block.

You have a policy that says that we could allocate down to a /28, but it’s a max that we can allocate in size is /24.

As a practical basis, as noted in this request, in this policy change, both ARIN’s tools are problematic if we allocate smaller than /24. And there’s two other sections in NRPM in Section 4, one for ISPs and one for v4, that provide a /24 minimum allocation.

And it’s not clear that the language in 4.10 is sufficiently strong to overcome the minimums elsewhere in Section 4.

So it’s rather problematic if you actually do want us to allocate a /28 and do lots of those to lots of people and not internally treat it as a /24, which is what we’ve been doing.

Therefore, this policy also changes something in a way that avoids a number of sinkholes, because it raises the minimum allocation to match what our practical internal usage is of /24.

We see the policy says /28. We have been treating it as /24. And we have basis in other parts of NRPM that says a /24 is what you want for IPv4 anyway.

Does that clarify, Andrew?

Andrew Dul: I understand. I disagree with one of your statements.

Paul Andersen: For the remote participants, Andrew is just stating he disagreed with one of the statements. So it be said.

We’re going to close the microphone shortly because we’re getting tight on time. So front microphone.

David Farmer: David Farmer, University of Minnesota, ARIN AC. It is technically possible for us to use /28s.

The thing is we need to look at who is using this policy chunk. It’s new entrants that need this chunk in order to – a v4 in order to do their v6. They are not the most sophisticated people that ARIN deals with.

Making it this hard – /28s are possible but they’re really hard. This makes it – using /28s makes it too hard for the unsophisticated users that are using this policy.

/24 cleans that – the /24 for max and min cleans that up, makes it easy to use. That’s the intent of this, is to make it easy to get a chunk of v4 so you can do v6. We screwed up when we added the /28 into it. It’s just plain and simple. We’re not perfect.

Paul Andersen: Okay. And, John, like if I understand correctly, because I want to make sure we talked about possibilities, there’s obviously the routability, which ARIN cannot guarantee, and that is what it is.

But there’s also the problem that the back-end systems that generate the zone files for DNS deal with the RPKI and just general registrations currently do not support, even if the policy was lifted, would require work to allow for /28s and such. Not saying they couldn’t be changed, but there would be significant work to do that.

John Curran: Right.

Paul Andersen: Those are two separate problems of the usability of a /28 versus the usability for us to allocate /28. I wanted to clarify those two policies.

Front microphone.

Michael Casadevall: Michael Casadevall, NARALO. I’m a little bit concerned that in cases where a /28 would suffice we’d be issuing a /24.

You can fit – if my math is right – eight /28s in a /24. We’re giving up a lot of address space for what we’ve already sparsely populated.

I think it’s worth the discussion, maybe not right now, to look at making the back-end system and the policy be able to issue smaller for /28 for those customers that can use it.

I’m okay with the default being a /24, but for people that know what they’re getting into, let’s not waste IP space unnecessarily, especially since there isn’t more coming.

Paul Andersen: Could be a good table topic for tomorrow on the ability for what’s the usefulness of those allocations.

We’re going to close the microphone after this speaker. So please approach the microphone.

Joe Provo: Proxying. Brian Jones, Virginia Tech: Should the 80 percent utilized threshold be raised since the allocation size is being raised to a /24 in this policy?

And also I support the policy 2019-3 as written.

Paul Andersen: Okay. Thank you for that. You wanted to add one comment?

Alicia Trotman: I love the energy and feedback I got today. On PPML I got one response. I want to see that energy in the fingers. Yes.

Paul Andersen: Microphones are closed. Final comment.

Joe Provo: Jason Schiller, Google, ARIN ASO AC, objects to the conflict existing as 4.10 is neither 4.2 ISP space, nor 4.3 end user space. So he doesn’t see the same conflict.

Paul Andersen: Thank you for that comment. That ends the input. Microphones are now closed.

Would you like an extra pair of glasses? You already have one. Thank you to our AC for presenting. That ends our policy today. Thank you all.

(Applause.)

John Curran: Okay. So we’re coming towards the end of the day, and we have one great presentation before we finish.

Our friends, Brenden Kuerbis and Milton Mueller, have done a study on economic factors affecting IPv6 deployment.

I think it’s an example of some of the information that could be presented to the ARIN community to illuminate how we’re doing in this world.

We talk a lot about IPv6, but we don’t talk about what’s actually happening. Hopefully their study will share some insights and get people thinking about where we are today.

Brenden, go ahead.

IPv6 Economic Factors Study

Brenden Kuerbis: I’m in the unenviable position of being between you and the beach. So I will hustle through this and try and get you out of here as quickly as possible.

So thanks to the ARIN Board for the opportunity to present this work on economic factors affecting IPv6 deployment.

This work was sponsored by ICANN’s Office of the Chief Technology Officer.

So despite more than a decade of evangelism on behalf of v6, the Internet community has not yet succeeded in moving the world to a new networking standard.

Technologies like NAT and secondary markets for v4 numbers have introduced major economic efficiencies that have extended the life of v4. Therefore, it’s not really correct to call the v4/v6 transition a migration really; rather, it’s a standards competition, and we need to understand better the dynamics of that competition and its implications for the future of the Internet.

Given this problem, we wanted to research what economic incentives affect decisions by operators to deploy v6 and what factors could best explain the observed levels of v6 adoption at the country level, and how do translation and tunneling technologies, which serve as a bridge between the incompatible standards, alter the economic incentives to remain with v4 or deploy v6.

As an academic, there’s an extensive economics literature on network migration. When strong network externalities are present, timing is everything. Adoption decisions are path dependent and converges on a common protocol is not reversible as it creates a lot of inertia and lock-in.

So when IPv6 was first developed, there was really no economic incentive, or motivation, rather, to adopt it. So it was v4, not v6, which spread like wildfire during the early years.

And widespread compatibility across the entire market raises the cost of switching to a new standard that is not compatible with the old one.

So the proposed dual stack migration model envisioned by v6 designers had two fatal problems. One is that it doesn’t reduce the demand for v4 numbers. And the other is that v6 deployers take on additional costs, while those who remain on v4 do not.

But some people have said that there’s a last mover advantage because of these problems. But I’d say that’s too pessimistic. A last mover advantage would equilibrate on everyone remaining on v4.

But fortunately for the transition, that’s not a correct view. Right? As a factual matter, there are first movers and there are numerous early movers.

On the other hand, though, those decisions seem to be independent and uncoordinated and almost randomly distributed across AS operators.

So IPv4 address space exhaustion is a constraint on an operator’s growth. Growth in the v4 Internet requires purchase of increasingly expensive v4 number allocations in the market and evermore intensive sharing of globally routed v4 numbers.

In contrast, v6 numbers are abundant and inexpensive, and deployment opens the door to less constrained growth. But deployment, v6 deployment, does, however, incur significant initial and ongoing costs that are caused by the necessity of maintaining compatibility with v4.

Because of that need for backwards compatibility, v6 deployment does not immediately eliminate an operator’s need for v4 addresses, nor does it eliminate the need to share those addresses.

So the key drivers of the deployment game then is an operator’s kind of subjective assessment of the value of network growth to its business and relative cost of that growth plan that involves either an IPv6 deployment or one that does not.

For a network that does decide to deploy v6, this cost of growth is a function of the initial cost to deploy; the infrastructure investments, the coding, the learning. Most of these are one-off in a single time period. Although, for larger networks there can be – they can be distributed over time in different parts of the network.

Plus the cost of compatibility to maintain backwards compatibility with the v4 Internet, including NAT translation or tunneling infrastructure, and the cost of running a duplicate protocol, and the costs of discovering and fixing things that are caused by the v6 deployment.

Plus the negligible cost of v6 numbers. For the network that does not deploy v6, the cost of growth is a function of extending the use of v4 by operating a NAT facility plus the cost of acquiring additional addresses in the market.

You guys are probably familiar with this. It’s data from the well-known APNIC measurement system that calculates for each economy an autonomous system, a percentage of user populations that have the capability to use v6 or prefer v6 connections.

In the aggregate view, the data does not really indicate that v6 is being ignored, but it also does not indicate that a technology is following a normal diffusion curve.

In many respects, aggregation of all the world’s networks into one graph or trend line is pretty misleading. For instance, when you drill down to the regional level, you see cases where more economically developed regions have higher adoption. In 2018, the Americas had stood at about 29 percent. In Africa, it’s about 1 percent.

There’s even variance between economically developed regions. For instance, the same time period Europe was at about 15 percent, about half of North America. Asia was at about 17 percent. And Oceania about 15.

To better understand adoption, we collected the average v6 capability measurements from APNIC for 215 economies, across a similar 120-day period in 2015, ‘16 and ‘17. And we validated that data against Akamai data. They’ve also taken v6 measurements and found it to be strongly correlated.

From that data we looked at 90-day smooth averages, and we identified countries with over 5 percent measured v6 capability in any one of the three years of the study. This figure shows these economies by growth trends that we observed. The vast majority, or about 80 percent, had no appreciable deployment.

That is, they remained at or below 5 percent. The next largest group were economies with increasing levels of v6 capability. And that was about 12 percent of the countries.

These economies were located around the world. The next largest group at about 8 percent exhibited plateaus in deployment with v6 capability stopping at levels anywhere between about 5 and 60 percent or, actually, 9 and 60 percent.

That group included numerous mature European economies as well as countries in other regions – Australia, Canada, Vietnam, Ecuador, Peru.

But the most accurate picture of v6 deployment comes from looking at adoption levels of individual ASes operating in the same market on a disaggregated basis.

This figure here shows v6 deployment for the top four ASes international market according to the samples collected by the APNIC system which is a rough proxy for market share, using the same measurement methodology I spoke of earlier.

In the US and New Zealand, what appeared to be gradual country-wide increases revealed to be plateaus for earlier adopters, which are then joined by new deployments by other operators.

Note, in New Zealand, of one of the top four ASes has not deployed v6 at all. And the earliest and most extensive deployer is a mobile operator that has plateaued around 50 percent.

This gives you a sense of some of the plateauing countries. And again, you see some variance between the operators, that they’re not all following the same pattern.

For instance, in Belgium, you see there was some coordinated action between operators with the regulator and three of them got up to around 75 percent. Although there still remains one operator that has no deployment there.

In the interests of time, we’ll skip through this. So we next developed kind of an economy level of dataset covering the 2015 to 2017 period looking at macrosocial factors in IPv6 adoption.

This included APNIC measurements but also world development indicators published by the World Bank, as well as fixed and broadband wireless, fixed broadband and wireless market concentration measurements as captured by the Herfindahl-Hirschman index from Facebook’s Inclusive Internet project.

Our findings so far are pretty consistent with our understanding of the economic incentives to adopt v6.

We found higher levels of v6 capability are correlated with greater country level GDP per capita because IPv6 deployment is costly.

Network operators in countries with greater wealth are more likely to risk money on it. Examples would be lots of fixed broadband networks in Western Europe, Japan, United States, Canada.

We also found higher country level v6 capability rates were correlated with lower levels of concentration in wireless and broadband markets.

This is not as straightforward to interpret but it does seem intuitive. A market with more players increases the likelihood that one of the firms will make a random decision to deploy v6. And in less concentrated markets it’s also more likely to permit new firms with no legacy infrastructure for whom the cost of v6 deployment is not much different than the cost of a v4 deployment.

So supply of v4 numbers plays a great role in the v4/v6 standards competition. The prospect of what some engineers called IPv4 runout was one of the main reasons for developing the v6 standard in the first place.

From an economic point, however, those resources don’t just run out; instead, as the supply diminishes, they become increasingly expensive and consumption patterns adapt to the scarcity with greater conservation and new forms of substitution.

And network operators have adapted to this tighter supply in two ways – one by using that, and the other adaptation is the secondary market.

Now, the incentives provided by the secondary market have led to the identification of millions of unused and underutilized v4 numbers by brokers and exchanges. And we see evidence of that in the adaptation in the v4 market data – we see evidence of the adaptation.

So reviewing the limited publicly available data that’s out there for pricing, we see the median price per address has doubled in four years from around eight in 2014 to 17 in 2018. And as one would expect, the range has narrowed as the market matured and initial kind of uncertainties about the values of addresses, the value of those addresses were resolved. And we corroborated these price trends with interviews with other address brokers.

These you saw this morning. We’ll skip that. The only thing I would mention in this is this is total addresses transferred, this kind of levelling off that we see in the amount of addresses transferred per year corresponds to the steady rise of prices and possibly indicates that supplies of untapped v4 numbers, blocks, are no longer expanding. Speculation, though.

So who is buying these resources? The answer is cloud service providers. So CSPs are a rapidly growing market, as we all know. Interviews revealed in terms of the numbers of customers and interconnected hosts, the cloud networks represent some of the largest networks ever connected to the Internet.

And while this market initially served or mostly served individual developers, enterprise use of them has grown tremendously over the last few years.

CSPs are buying v4 numbers because enterprise networks are lagging behind in IPv6 deployment relative to the public provider networks.

One interviewee said that only about 5 to 7 percent of enterprise network traffic is v6-enabled. And that assertion can be corroborated by NIST estimates, Department of Commerce estimates, of industry v6 deployment.

Enterprises are also slower to upgrade applications currently if they have current revenue from them. This drives demand for v4 addresses amongst the cloud providers as each instance of service that they’re providing to these customers may require a globally routed v4 address.

But you have other networks acquiring v4, including the growing ISPs, such as Charter and Indian Mobile, Reliance Jio, which, while using v6, still have great demand for v4 given the scale of their networks and the need to connect to IPv4 hosts.

We next modeled how an operator’s requirements for a globally routable v4 addresses over a 15-year period are affected under two transition cases, both dual stack and conversion, specifically 464XLAT. In both cases we assumed conservative carrier-grade NAT configuration values based on equipment provider manuals, RFCs, this type of information.

The model allows us to explore the way that operators need for v4 addresses is affected by the various subscriber baseline values and growth rates in those subscribers, as well as the baseline value and growth of IPv6 capability and operators traffic matrix ratio at their gateway.

This provides insight into how v4 address scarcity might create some incentives to deploy v6.

Now, as we discussed the model, it’s important to keep in mind that the reasonableness of the assumptions regarding growth in network size and the shift in the v6 ratio vary obviously across each of the 60,000-plus ASes. Operator diversity means that any number of outcomes could be possible.

Decisions regarding v4 address acquisition and v6 deployment take place on an individual operator basis and will reflect that diversity and conditions and incentives.

The best we can do is show some various scenarios and discuss their implications for the transition.

So here we’re showing a large mobile network with a fast subscriber growth rate of optimistic 15 percent per year, coupled with a slower 5 percent annual shift in the traffic ratio towards v6. The levels of v6 traffic are assumed to start around 44 percent, which is the number observed in the United States.

These assumptions produce an inflection point after about 10 years where the network’s technical requirements for v4 addresses starts to decline.

This happens when the traffic ratio is near 74 percent v6. If the subscriber growth rate were lower, then the inflection point occurs earlier, that is, it shifts to the left on the X axis at a lower v6/v4 traffic ratio.

Now, the model is also sensitive to the specific patterns of growth that I had mentioned. Growth could be either linear, accelerating, plateauing, follow an S-curve.

So, for example, if the subscriber growth rate slows down and it starts to plateau after about seven or eight years and the IPv6 traffic ratio follows a more rapid S-curve in growth pattern, the operator’s need for v4 numbers starts to decline after only four years and approaches zero after 15.

However, a different set of assumptions for a different type of network tells a very different story. This figure shows a small enterprise network that only has 10,000 users and grows only 2 percent a year.

The traffic ratio shifts towards IPv6 at the linear rate of 4 percent a year. But since the enterprise is located in an older legacy environment, software and hardware environment, the starting point for v6 traffic ratio is set at 22 percent rather than 44.

In this case, the implementation of v6 doesn’t do anything for the operator. Its v4 numbers increase modestly, whether or not it implements v6. So the additional expenses for deploying it really wouldn’t reduce its demand for v4 addresses by a worthwhile amount.

And while its v4 number requirements would also increase without v6, the small scale of the network means that the additional numbers are needed, only about a thousand to 1500, would not be that expensive or hard to come by.

At worst, NAT could be tweaked to stretch their address assignments further. In general, for smaller-scale networks, the gains from v6 deployment don’t appear to justify the expenses. For such networks, it makes sense to continue to extend v4.

Not until the market value of those addresses held by the network exceeds the enterprises cost of transitioning to v6 would there really be an economic incentive for them to change.

However, not all enterprises own their v4 addresses. And in those cases there may be pressures to shift from an upstream service provider.

So we’ve seen a scenario where we had a growing mobile operator that may be in a position to sell surplus v4 addresses back into the secondary market. But it’s also possible to posit scenarios where large providers might want to hang on to their v4 numbers.

This figure represents assumptions about a major cloud service provider. It assumes 60 million subscribers to start with an S-curve growth trajectory in their numbers over 15 years. The v6 traffic ratio is assumed to grow rapidly at first but then plateau at around 70 percent.

We have also assumed a lower starting point for the v6 capability traffic ratio because CSPs interact with a lot of enterprise networks likely to have lower v6 deployment rates. So the models show the v4 requirements for CSP declining steadily for five years while the traffic ratio shift rate exceeds the subscriber growth rate.

As the shift rate levels off, however, the requirement for v4 numbers starts to increase again as the subscriber growth continues.

Thus, some operators might, despite experiencing increases in v6 traffic and declines in their immediate v4 requirements, continue to hold onto v4 resources, in the face of uncertainty about future v6 traffic ratio and v4 prices.

While the traffic ratios are operator-specific, such a scenario definitely could occur given numerous economies that are exhibiting plateauing growth currently.

So, in conclusion, there’s good news and bad news in our findings for IPv6. The good news is that v6 is unlikely to be what’s called standards orphan.

For network operators that need to grow, particularly mobile networks where the software and hardware ecosystem is mostly converted, v6 deployment can make economic sense. It mitigates major constraints on growth and can provide a path out of the operational complexities and costs of large scale NAT.

Our modeling of the dual stack and conversion method shows that for a fast-growing network, v6 deployment contain, but not immediately eliminate, the requirement for more v4 number resources.

The key variable is how quickly that traffic ratio shifts towards v6 and the rising price of v4 numbers provides an additional stimulus to deploy.

The bad news is that the need for deployers to maintain backwards compatibility with non-deployers eliminates many of the network effects that would create pressure to convert to v6.

Additional bad news is that many enterprise networks don’t need to grow much and/or maybe still lodged in slower-moving hardware and software systems tied to v4.

Another issue that emerged from our modeling exercise was that once the IPv6-only traffic ratio among v6 deployers reaches a certain level, their v4 address requirements start to decline.

Now, these operators in theory could therefore release v4 addresses into the market and that would alleviate the shortages and facilitate continued low levels of growth for legacy v4 networks.

So given this complexity, it’s hard to – and the independent, the number of independent actors and the different scenarios that they’re facing, it’s hard to posit scenarios that lead to kind of global convergence on v6 within 20 years.

And it makes sense to consider the implications of what a mixed world means. Right? Including the architectural, economic and policy implications of a mixed world. Thanks.

(Applause.)

John Curran: Okay. Any questions? We just learned we’re going to be looking at v4 for a while. Lots of opportunity for new policies.

(Laughter.)

Any questions? Last chance. It is kind of harsh being between here and the beach.

Thank you for coming, Brenden. Thank you for the study.

(Applause.)

Public Policy Meeting, Day 1 - Closing Announcements and Adjournment

John Curran: Okay. With that, I will now do the closing announcements and adjourn us for the evening.

So thank you for our sponsors, our two sponsors, C&W Business and Google, network and webcast sponsors. Big round of applause.

(Applause.)

Meeting sponsor, Addrex. And our Silver Sponsor, IPv4Mall.

(Applause.)

Okay. We have a women’s networking reception. It’s in the Needhams Ballroom. It’s actually starting now and going about the same time. So Needhams Ballroom 3 if you’re interested in that.

Tonight’s social is at Copacabana. There are buses to get there. Your badge or your social badge, which is inside, will get you in.

You must have a badge to get on the bus. You must have a badge to get in. So bring your badge. Either badge will be fine.

Shuttles run from this level, the elevators. The hotel lobby, it’s a level above us – you have to come down to the ground level.

If you go out the doors, turn right in the circle to the lower level, just walk out the door to that circle, that’s where the buses are going to be. 6:45, 7:00, 7:15.

Return shuttles will begin at 8:30. Barbados experience: buffet, favorites, beach games and wonderful views. So it should be a wonderful social.

Reminders. Tomorrow, breakfast at 8:00 next door. The meeting will start here at 9:00 AM.

Thank you. Our meeting materials are all online if you want to know what’s set up for tomorrow.

Thank you and that’s it. Look forward to seeing everyone at the social tonight. Take care. Goodbye.

(Applause.)

(Meeting Adjourned at 4:35 PM.)

Network Sponsor

Webcast Sponsor