ARIN XXV Public Policy Meeting Draft Transcript - 20 April 2010 [Archived]

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

Meeting Called to Order

John Curran: Welcome back to the ARIN XXV meeting in wonderful Toronto. I see people are lively and awake. I’d like to do a couple of announcements. First today: we’re doing surveys. Today will be no different. You need to go online to fill them out. You have between 8:00 a.m. and 6:00 p.m. to the prior day. This includes remote participants.

Today we’re going to do a prize drawing and here’s our time for our drawing. So I will choose someone. Stacy. Perfect. I need you to stand here and close your eyes.

With no one injured in the process, I’d like to announce, Jim Kirby of Dataware. Are you here, Jim? Jim Kirby. You don’t have to – we’ll give him a prize. He’s entitled.

Sponsors: We have two sponsors. TELUS providing network connectivity, and EGATE. I’d like to have Matthew come up from TELUS to give us a few words. And you’re going to project.

Matthew Wilder: Thank you, everyone. Welcome. I am pleased to be able to represent TELUS as the IP address manager and to represent TELUS here this morning. TELUS is the network connectivity provider.

Just a few words for TELUS: before I do that, there have been a few hurdles getting to this point, but I’m very pleased to be here. It’s very gratifying to see the networks up and everyone’s able to continue their plugging away on laptops: very exciting to see.

So a little bit about TELUS: TELUS is the leading telecommunications provider in Canada with consumer business and partner clients. And in particular I’d like to point out our Partner Solutions business, which has so graciously sponsored this meeting.

So without further ado, looks like I’m skipping ahead a little bit. So Partner Solutions prides itself on building trust and relationships with our peers. If he doesn’t skip ahead on me somewhere. So our peers include many of you here.

You represent many of our clients which would be all the global carriers for sure and a lot of Canadian ISPs. So we definitely represent – you represent a good part of our client base, actually. And because TELUS prides itself on the trust relationship it builds, we get a lot of accolades as far as how we do in the industry. And this is one of the most recent one.

Keep skipping ahead. TELUS was named Best Regional North American Wholesale Offering for 2009. And this is one of many accolades, and I think it’s because TELUS Partner Solutions has a team committed to the success of our peers. And I hope many of you can enjoy that relationship as well.

So, finally, I just would like to say it’s great to see so many of you committed to moving the Internet industry forward. And as a community we face unchartered territory, and we need visionaries like you to move the Internet forward.

I’ll thank you for doing that with sound policy development. So thank you and welcome to TELUS.

[Applause]

John Curran: Okay. We have a number of exciting things on the schedule today. I want to remind everyone that – to ask people to speak clearly and identify themselves when they’re at the microphone. That will help everyone.

Members of the press, they’re busy covering the meeting. If they want to quote you directly, they will approach you and ask for permission: just something for everyone to keep in mind.

One other little announcement: I said it yesterday. When you go to the break rooms, the lunchroom, please eat the food there. Don’t bring it in here because we don’t get in here to clean these rooms during all the breaks and all the lunch breaks as would be hoped.

So we’d like you to eat lunch out there at the lunchroom if at all possible. Help keep a clean meeting.

So today, for reports, we have the IPv6 IAB/IETF Activities Report, which will be given by Marla. And we also have an NRO NC Report and NRO Activities Report, and then the AC will do its On the Docket Proposals Report.

We also have a number of policy discussions. We have a Simplified Ipv6 Draft Policy, and we have the Rework of the IPv6 Assignment Criteria, both on today’s agenda.

And then in the afternoon we have a waiting list criteria, waiting list for unmet IPv4 requests that we’ll be discussing.

At the head table today, we have Stacy. We have Bill Woodcock. I should know all these people: Tim Denton, Bill, Paul Vixie, Lee Howard, and Owen.

The head table helps facilitate discussion. They’re also up here thinking and paying attention to what you’re doing. And to the extent that they see something that might be a relevant question for the audience to think about, they pay attention. They also help me. Sometimes I can’t see the full range of all the microphones, and they’ll send a little message my way that I’m missing someone.

So to the extent that you’re wondering why we have a head table, that’s the purpose it’s served over the years.

Okay. Without any further delay, let me first call up Marla Azinger to do the IPv6 IAB/IETF Activities Report.

IPv6 IAB/IETF Activities Report

Marla Azinger: I’m Marla Azinger. I work for Frontier Communications. First, thank you, everybody, for sticking with me yesterday when I was on the Sudafed. I haven’t taken any in 12 hours now, so hopefully I do a lot better today with memory recall.

So here we go. This is the IETF Activities Update. And the last one – I updated everything just this last week. So just a note that not everything may be exactly up to date, because the working group chairs don’t always get their specific websites updated.

So some of it – some documents may actually be further in the process than what’s in this presentation as far as under IESG review, things like that. This is not an official IETF report, because IETF does not have an official liaison to ARIN or any RIR.

But I believe it’s accurate, as much as I could make it. And any errors, they are my responsibility. So let me know if you see one. And the presentation is not a detailed review of documents.

I’m doing this a little different than I have in the past as well. I realized I go through all these documents and a lot of people probably glaze over because it’s just titles and little bits of what documents are about.

But what might be more important to address is what these groups actually do. And so this time I added what the groups do. So you get a little bit more familiar with IETF if you’re not.

So IPv6, maintenance: The six-man working group is responsible for the maintenance, upkeep and advancement of IPv6 protocol specifications and address and architecture. This working group will address protocol limitations, issues discovered during development and operation.

It will also serve as a venue for discussing the proper location of working on IPv6-related issues with IETF. And right now they have five active documents. IESG is processing two – I’m sorry. There you go. And editing: The IANA allocation guidelines made a fast track to the RFC editing queue.

V6 ops: The IPv6 Operations Working Group develops guidelines for the operation of a shared IPv4, IPv6 Internet, and provides operational guidance on how to deploy IPv6 into existing IPv4-only networks as well as into new network installations.

Right now they have six active documents, four of which are under continued revisions. And the newer document addresses carrier grade NAT, and this document might be of interest to some people with larger networks. The document proposes an incremental carrier grade NAT approach for IPv6 transition. It proposes that CGN can provide IPv6 access services for IPv6-enabled end host and IPv4 access services for IPv4 key v4 end host while remaining most of legacy IPv4 ISP networks unchanged.

That was a mouthful. Sorry.

SHIM6: The SHIM6 Working Group is chartered to track the implementation and testing or development effort of the layer three SHIM for providing locator agility with fail-over capabilities for IPv6 nodes. The group is also expected to shepherd to completion a few remaining informational documents that complement the existing protocol specifications.

There hasn’t been too much action in the SHIM6 group and only two active documents that keep getting revised. And Geoff is the –

Geoff Huston: Any day now.

Marla Azinger: Geoff, as you can see, is the man for SHIM6.

Behave: This working group documents best current practices to enable NAT to function in as deterministic fashion as possible. Due to the working group’s experience with translators and their behavior, it has been given the task to help encourage migration to IPv6 and to support deployments where our communicating host requires using different address families at EIPv4 or IPv6.

Address family translation is needed to establish communication. And in Behave specification work on this topic it will coordinate with the v6 Ops Working Group because a lot of the documents really need to work together on requirements and operation considerations. And there are nine active documents in this group right now.

And continuing, IESG is proxying one document. And the RFC editor is working on three documents. We’ll go through this lovely long list, you’ll see this.

SIDR: Not to confuse – there’s two different CIDRs. This is the one that starts with an S, Secure Inter-Domain Routing.

The SIDR Working Group will develop security mechanisms which fulfill those requirements which have been agreed on by the RPSEC working group. The Routing Protocol Security Group has been chartered to document the security requirements for routing systems, and in particular to produce a document on BGP security requirements. In developing these mechanisms, the SIDR Working Group will take practical deployability into consideration.

And they dropped from 12 working documents to eight, so some fell off the radar.

Softwire: The Softwire Working Group is specified in the standardization of discovery, control and encapsulation methods for connecting IPv4 networks across the IPv6 networks and IPv6 networks across IPv4 networks. In a way, that will encourage multiple interoperational implementations. And it’s still keeping busy.

And the 6rd, which is the next presentation I’m going to give you, is in this working group and it’s now with ISG being reviewed.

DNS Operations: The DNS Operations Working Group will develop guidelines for the operation of DNS software servers and the administration of DNS zone files.

These guidelines will provide technical information relating to the implementation of the DNS protocol by the operators and the administrators of DNS zones. They have five active documents and two are newer of those five.

DNS Extensions: This working group will actively advance DNS protocol-related RFCs on the standards track while thoroughly reviewing further proposed extensions. The scope of the DNS Extension Working Group is confined to the DNS protocol.

Particularly changes that affect DNS protocols on the wire or the internal processing of DNS data, DNS operations are out of scope for the working group.

And they’re staying busy with nine active documents, and they’re making progress on those documents. Two of these documents are in the RFC editor’s queue and two documents are under IESG evaluation.

OPSEC: Operational security capabilities for IP networks. This working group will document best current practices with regard to network security. In particular, an effort will be made to clarify the rationale supporting current operational practice, address gaps – addresses gaps in currently understood best practices for forwarding, control plane and management plane security and makes clear the liabilities inherent in security practices where they exist. And this group has five active documents.

GROW: Global Routing Operations. This group is to consider the operational problems associated with the IPv4 and IPv6 global routing systems, including but not limited to routing table growth; the effects of the interactions between interior and exterior routing protocols and the effect of address allocation policies and practices on the global routing system.

GROW has seven active documents, and there’s one document – Simple Virtual Aggregation is an interesting document that some of you might want to take a look at, and it’s concerned about the FIB size. So if the FIB topic has been new to you here this week. Go ahead and take a look at that document.

LISP: This is a newer working group, and it’s trying to come up with an alternate architecture to the Internet. So the LISP Working Group is working on an alternate architecture and is not chartered to develop the final or standard solution for solving the routing and scalability problem. Despite that was the impetus of its creation and the rationale.

Its specifications are experimental. And they’re labeled with accurate disclaimers about their limitations and not fully understood implications for the Internet traffic.

In addition, as these issues are understood, the working group will analyze and document the implications of LISP on Internet traffic applications, routers and security.

The analysis will explain what role LISP can play in scalable routing. And now it should also look at scalability and levels of state required for the encapsulation, decapsulation, liveliness and so on, as well as the manageability and operability of LISP.

So, like I said, this is a new working group, so if you want to dabble in something that’s completely different to the current architecture, that’s where you want to go look.

The next conference is in Maastricht, IETF 78. The BoF wiki summarizes recent upcoming BoF activities, and here’s just some links that you can use to go look up information. And then the references, more references.

Datatracker.ietf.org/workinggroup has proven to be one of the easiest links to use if you really want to find information quickly. There are search engines, but if you don’t know what specifically you’re looking for, the search engine can be really difficult so you’re best off going to that site.

And then the IETF Daily Dose is kind of like a newsletter for IETF. And so if you just want to go look and see what’s going on and maybe get updates and try and start getting with whatever programs are going on at IETF, that’s a good spot to go to.

And that’s it. Any questions?

John Curran: Any questions on the IETF report?

Thank you, Marla. Sorry.

David Williamson: David Williamson, Tellme Networks and Microsoft. Thanks for producing this. I’m sure it’s a fairly thankless task to wade through working group lists and it’s very exciting.

You mentioned LISP. I wanted to highlight one point about LISP. It’s currently listed as an experimental working group. So it’s not actually something that’s being produced for wide deployment yet.

And it’s complementary with the Routing Research Group for the IRTF, which is a research offshoot.

So do you know how LISP and RG are interacting with the GROW group? I don’t follow GROW, so I don’t know what interaction there is there.

Marla Azinger: I didn’t make it myself to GROW. There were too many overlapping meetings this last time. I don’t know the answer to that. I can – unless maybe Chris knows. Otherwise I can contact people and find out.

Chris Morrow: Chris Morrow, Google, ARIN AC. So for aside from just trying to keep track of what LISP, for instance, does, the GROW Working Group isn’t paying a lot of attention to LISP until they come and say something.

So the folks in GROW have gone to LISP stuff. LISP has presented several times at GROW. And every time they do, there’s lots of interest. So it’s moving along.

David Williamson: Cool. Okay. I also want to note that the Writing Research Group is nearing a recommendation. So people who are interested in routing growth should go pay attention to that. It is not a consensus-based recommendation, which is perhaps interesting to note. So you might want to take a look at that.

John Curran: Thank you.

IPv6 Rapid Deployment (6rd)

Marla Azinger: I’ll do my best to channel him, but I’m not sure how well that’s going to work out. So there’s three of us involved with this, Alain and myself and Mark Townsley.

And Mark Townsley is one of the original draft writers for 6RD IETF. And he was heading this up at Comcast and who kind of decided presentations need to be done to make sure that everybody knew about this ability. And then they pulled me in to make sure that policy in our region gets addressed the best way possible.

So I’m trying to cover two other people, so bear with me and I’ll get through this presentation.

So we have 6RD. It’s an IPv6 overlay on an IPv4 access. And it needs to be topologically aligned. Offers dual-stack IPv6 to the subscriber premise. The access network remains IPv4. It’s simple, stateless, automatic IPv6-in-IPv4 encap and decap functions. And the IPv6 traffic automatically flows IP routing to a border router. That’s the topological part of this.

So this I think is Alain’s favorite slide, because he gets really giddy about this is where 6RD lives. So 6RD is a residential gateway. It’s dual stack.

On the LAN side, you have production IPv6 service plus NAT’ed IPv4, and then IPv6 Internet access delivered to the home allowing IPv6-enabled applications and content to remain unaffected by IPv4 exhaustion.

So this is when you have your IPv6-capable customers but your network may not be so up to par with IPv6.

On the WAN side, you have IPv6 via IPv4 global or private IPv4. And then the IPv6 and ISP network evolves at its own pace, which the next slide will show.

I put them in a different order. Sorry. We’ll get to that piece. This created the standards track, which is what Mark – he co-authored this. I’m sorry, I’m forgetting the name of the gentleman that co-authored it with him.

But it’s at IHS. It’s version 8 right now, and it’s at IESG review. And there is one big company that has deployed 6RD and is doing very well with it.

Here’s the timeline I was talking about. So 6RD and native DS-Lite will co-exist in the same network. They’re not competing. And that was a point Alain wanted me to make sure to point out to you all. And 6RD tunnels v6 inside v4 and DS-Lite tunnels v6 inside v4.

6RD in the beginning – what you can start in the beginning is kind of the rapid deployment you can do. And then as you move to phase two, you can have native dual stack and start getting the rest of your network up to par.

And then 6RD can coincide with that, and you can run them at the same time but you can wean yourself off of 6RD and on to your dual stack. And then eventually, depending on what size your network is – obviously you may not need all of this – or what’s going on with your network, but phase three would be dual-stack lite. IPv4 over layover IPv6, or you have NAT444. It’s all depending on what your network’s like.

Okay. The minimum space. So if an ISP offers only one /64 subnet per home, there’s a need for a /32 IPv6 prefix.

And that’s one of the reasons why I got involved with policy, to make sure that people can get access to the IPv6 space they need in order to do 6RD in conjunction at the same time with AW6.

Assuming that an ISP has IPv4 space that is not contiguous, the ISP offers several /64 subnets per home. There is a need for more than a /32, and that’s because of the breakdown.

And IPv6 /28 prefix then would obviously enable 16 subnets per customer. Some people will question why it is that a customer would need that many subnets, but it goes into the whole discussion of do we really know what people are going to be doing on the end in five years from now. And, surprisingly enough, I actually do have some customers that have a situation like that with v4. And I’m sure other people do, too.

So the potential policy part. If you have disjointed IPv4 blocks – these are suggestions as to what could exist for policy. And I don’t want to move on to this too far because the goal isn’t to make a new policy if we don’t need one.

And I discussed this with Leslie a few times, and we weren’t really sure if the current policy really covered it well enough for the staff to be able to comfortably say, okay, yes, I’ll give you a second /32 in addition to the /32 you’re already using for your native v6.

So because of that kind of iffy space, we wrote up a draft proposal so that 6RD would be approved for use in the ARIN region.

So some of the finer points of it: If you had disjointed IPv4 blocks, you would automatically qualify for a /32 for use as a 6RD. And if you want more, up to a /28, because of that reasoning, if you wanted your customers to have more than one subnet, then you could justify why, and that would fall into regular justification as to why your customers need that much space.

We put “allocation would be reviewed every three years” because there’s a gigantic possibility that you only need 6RD for the beginning.

And if you only need it for the beginning, then you can roll out of it, that means you can hand that address space back to ARIN when you’re done with it. So we put three years as a marker so that there would be a follow-up with ARIN as to whether or not you really need that address space still. And if you don’t, you would hand it back to ARIN.

However, we do want to make sure that it’s done in a smart manner. And we would – in the draft proposal we suggest that you actually, if possible, give them contiguous space to whatever their original IPv6 allocation is, because if by chance they get to the point where, okay, you can hand back this stuff because it’s not on 6RD, but, oh, if you look at the usage on this /32, it’s already to the point where we need to go back to ARIN for more v6 space, then obviously they’ll just change that into regular use and no longer 6RD, whatever they can justify of that 6RD allocation.

So we’re considering submitting a proposal for that. This is the policy statement. And we will submit it. I’m seeing Leslie nod her head, so I’m thinking we probably do want to submit the draft in order to have everybody look at it and mull it over and get feedback on it so we can get it going.

There’s people already using 6RD in Europe, and I believe APNIC has some users as well. So some people are a little antsy to make sure that this option is available to everybody in the ARIN region as soon as possible. It’s very understood that we have certain timelines and a cycle that we follow with policy.

So we’re going to be doing our best to try and get feedback on this and hopefully get it passed so that anybody that’s trying to do rapid deployment with v6 and get their v6 users actually up on the net, that they can.

I didn’t make a question slide. So I don’t think I did. No, I did not. Here’s the rationale as well. But that will be posted to PPML.

Any questions?

John Curran: Microphones are open. Far left microphone.

JF Tremblay: I’ll go first. JF Tremblay from Videotron. As the medium-sized ISP in Quebec, we have a fair number of disjointed blocks, and we looked at implementing 6RD. And presently I think there’s no justification in the current policies to get a new /32 to do that. But we would be interested in doing it. So we are actually supporting this, the proposal – well, the would-be proposal.

Marla Azinger: Thank you.

John Curran: Center rear.

Geoff Huston: Geoff Huston, APNIC. As far as I understand, 6RD is a variant of the original 6to4 technology. In essence, what it does is it takes the v6 address and folds it inside the v4 address and folds it into a v6 address and uses tunneling across the v4 network.

The difference lies, as far as I can see, in the way that certain operating systems, and in particular, Windows, Vista and Windows 7 treats 6RD as compared to 6to4.

What we see at the moment inside deployed systems is that on these lighter versions of Windows, the preference in terms of the way things work is if it uses a standard unique housed v6 address on the local host, it will try that first.

It will then try v4. And it will then try either 6to4 Dorado as a third choice. The reason behind that lies largely with some observed issues particularly with fragmentation handling across tunnelled protocols. There are certainly some issues around that, particularly with the treatment of ICMP.

6RD behaves differently, because the host thinks it’s unicast but it’s not. So the question is: To what extent has 6RD uncovered or at least encountered problems that are not normally visible with 6to4, because of the subtle difference in the preference order of use, between 6RD and 6to4?

Marla Azinger: So, unfortunately, I don’t have any data. That would be Mark or Alain that knows what problems have been encountered. I haven’t been told of any problems. I’m sure everybody gets glitches no matter what. But I don’t know what they are. But I can find out and I can post it to PPML.

Would that work for you, Geoff?

Geoff Huston: Yes.

Tony Hain: I think I can answer it. So as long as you get the MTU message in the RA that says that the MTU on the upstream is less than 1500, you’re okay, because you don’t try to go there.

So I don’t believe that that’s a problem in the current deployment that’s out there today. I don’t know that the boxes that are about to be deployed are doing the right thing with the RA. I will go home and test that.

Marla Azinger: That’s Tony Hain from Cisco.

Geoff Huston: Geoff Huston. One follow-up here: I think it would be useful to the operating community to understand a little bit more behind Microsoft’s decision on the way in which it relatively preferenced 6to4 and Dorado versus unicast v6 and v4 and understand the interactions of that against 6RD.

Tony Hain: And I won’t tend to speak for Microsoft. But having been a program manager in the past on a particular v6 implementation that shipped from there, the intent there is that a native announcement, whatever the prefix is that’s in that native announcement, gets preferred over the embedded tunneling protocols. And the tunnel interface has a metric associated with it that causes the tunneled interface, prefix independent again, to look like a higher cost thing.

So even in my house, it’s announcing a 6to4 prefix natively. The Windows machines don’t know that. They just see an announcement. They think it’s a native announcement. They’re not doing tunneling. They don’t get that bias.

But if I had turned off the RA, then they would go ahead and do that. So it’s an interface metric-based approach that causes Windows to de-preference things, and then there’s the policy table on top of it which looks at the actual prefix being used and says which one gets preferred over which v4/v6. It’s a double preference thing. It’s not real easy to explain. And it’s different in every version of Windows. Trust me.

John Curran: Microphones remain open.

Owen DeLong: Owen DeLong, Hurricane Electric. I definitely would like to see this move forward as a policy proposal as quickly as possible. I think that 6RD has proven to be a very, very workable solution in the free.fr experiment as it’s gone so far.

Last I heard that they had something close to 30 percent customer adoption on a voluntary basis. So if you think your customers don’t want v6, look at the free.fr experiment in more detail.

And I would encourage people that can’t deploy native v6 right away on the IBAL level to seriously consider this.

Marla Azinger: That’s also how I got roped into this, because I’m looking at that as an option with our regional team and the core team for use of this.

Tony Hain: Tony Hain, Cisco. I support the concept. I’m a little troubled with the focus on /32s and even /28s.

The fundamental issue I have is the perception that everybody gets a /32 and I tell anybody that has a significant number of customers that if they have a /32, they did the wrong thing, go back to ARIN and return it and get a real block.

Because if you’ve got a significant number of customers, a /32 is not going to cut it. And having this thing associated with a similar sized block and not putting it in the context of you’re a big ISP, you’re going to get a big block, and a subpiece of that block should be for 6RD functionality.

All the rest of what you’re saying is fine. But I’m troubled by the /28, /32 conservation mindset that is not helpful.

Marla Azinger: Okay. So we put conservation in it just because there are people that also want the conservation. And the /32 is there because that has to be the minimum and it has to be separate from any /32 that they’re using for native.

If there’s wording that you actually would prefer – because I am going to post this to PPML. And we don’t have any issues with working with what suggestions people send us for revisions. So I’d love for you to actually send some revisions once I get this out.

Tony Hain: I’ll be happy to send text. Like I said, I’m troubled by the focus on specific links as opposed to saying you can justify an additional block for your 6RD deployment and leave it at that. Because I think that’s really what staff means.

Marla Azinger: That’s how our document first started.

Tony Hain: They just need to justify additional deployment. They don’t need to necessarily spell out size here.

Marla Azinger: Right. Thank you.

Lee Howard: Lee Howard, ARIN Board of Trustees and Time Warner Cable. Two things: One, I think it’s a great topic for the Open Policy Hour. That’s what it’s there for.

And then I have a question about this proposal, that because it’s stateless, there may not be a way to gather the HD ratio utilization metric for this kind of utilization. But there might be.

And I haven’t – it’s not clear to me whether it’s, whether we actually need a new policy if we can substantiate need based on HD ratio for additional blocks. But that’s a question. I don’t know.

John Curran: Okay. Far right microphone.

Michael Richardson: Michael Richardson, Sandelman Software. My question is again the focus again on the /32, and I guess two concerns is that for ISPs that don’t have too many prefixes, it seems that at least maybe the left 12 to 16 bits of the v4 address is kind of redundant and well known possibly by then.

And so they actually may not need quite so much if they want to do that, or if they want to give the customer more than a /64, they may want to do that. So I’m a little bit like I can see it’s much simpler if you just give everyone a /32. But I guess my related concern is that it seems like the ISP is going to have to deploy some BOCs to the encapsulation.

And if the policy side were focused on you need to have a /32 to do this, then I suspect the implementations will say you need to have a /32 to implement it. And I guess I’d like to see that a little bit less nailed in stone. And if we’re a little bit vague on what the size is, maybe the implementations will also be more flexible.

So I can see this being used for other things than just a specific – the model being used for other things than just the specific home user DSL environment.

Marla Azinger: Right. And whenever I see subnets – I’m glad you guys are all leery when you see subnet sizes. Because I get leery when I see subnet sizes in proposals, too.

That 32, we’ll have to work with the words and the statement. When you read the statement, you’ll say, no, that’s not clear enough or it’s not open enough. But the main part of that was to make it clear to ARIN staff that if someone is going to do 6RD, at the minimum they have to have a /32. It’s not supposed to be a barrier that you only get a /32. But justification’s actually supposed to be a heavy part of this. But the /32 is where you have to start.

Unidentified Speaker: I think to add on what Lee mentioned earlier, I think his comment was actually how is the actual justification done after three years? Because the HD ratio cannot be used as it’s used now to justify the allocation, that’s for sure. And actually the density is the same than the v4 density of that specific ISP except much lower because actually it’s divided by – for example, I have about 30 blocks so my density is 30 out of 65,000.

So, I mean, I’m only using – for 6RD I’m only going to be using approximately .4, .5 percent of the /32 actually. So it doesn’t fit within the current justification. So we have to provide a different type of justification for that space. That would be great to have that specified in the policy as well.

Marla Azinger: It’s on the list. Thank you.

John Curran: Anyone else at the microphones?

[No response]

Okay. Thank you very much, Marla, for that presentation.

REST & Relax - The Future of Whois and Templates at ARIN

Andrew Newton: Good morning. I’m up here to talk about the future of WHOIS and templates at ARIN and the RESTful services that we’ve been talking about.

There are basically two RESTful services that I’m going to talk about today. The first is the WHOIS RESTful Web service which we announced back in November. And that will be going into production shortly in July.

And the next one is a RESTful Web service that I alluded to yesterday in my presentation, but this is a separate service, which is really for doing provisioning or managing your resources that you have with ARIN. And going along with community feedback, this service has built-in compatibility with e-mail templates.

So, first off, let me talk about the WHOIS RESTful Web service. The RIPE NCC – if you don’t know this yet, the RIPE NCC has also started their own RESTful Web service for WHOIS data. And I guess the best way to think about that is imitation is the sincerest form of flattery.

They just announced this, I think, last month. And in fact they’ve already put up one update to it. Anyway, I do encourage you to go look at what they’ve done. It’s very interesting work. They took a different approach than what we did, but it’s still very interesting work. And there’s the URL for you, if you want to go look at their work.

As far as the status of our WHOIS RESTful Web service, we’re almost ready for production. We’ve been doing work back at the office for load testing. As Mark mentioned in November, we’ve been seeing a lot of WHOIS load, load on our WHOIS servers going up and up, and he’ll show on the graph, I guess, tomorrow that’s a continuing trend. Hasn’t stopped.

So one of the things we’ve been doing is we’ve been load testing our own software, our new software that’s going to go into production. Because we want to make sure that once we deploy the service we can handle the load. We’re doing a pretty good job of that.

The other thing is we’ve been incorporating feedback. So there have been people who have made suggestions on how to improve the service and better queries that we can support. So we’ve implemented a lot of new queries.

We’re trying to improve the documentation. And along those lines, we’re formalizing the XML schemas in Relax NG. Finally, as I mentioned yesterday, we’re doing POC validation. That will be coming up pretty soon.

So one of the things we’re doing with POC validation is in WHOIS you’ll be able to see whether a POC is valid or not. And as we speak, the people back at the office are actually putting that code into the software.

So when we deploy WHOIS-RWS, the Port 43 servers that we run on the nickname WHOIS protocol will actually be switched over to an RWS proxy that will actually get all the information out of the RESTful Web service. So that will go into production when the WHOIS-RWS production goes into service as well.

One of the things we’ve added is CIDR queries to that. We said back in November we weren’t going to do that. There were a lot of requests for please could you, and we went back and looked at the code and, sure enough, it was feasible to do. So we’ve done it.

The other thing that we’ve done is we’ve added better help and error messaging. So when you enter a query into the WHOIS system, if it does not parse correctly, instead of trying to search for everything on the planet for you, we’ll actually tell you what you put in wrong. Or when the service assumes that you’ve given a certain type of query, it goes ahead and issues it for you. It will actually let you know what it assumes you tried to do.

Another thing is some of the WHOIS clients don’t like the dot name attribute flag. It’s not that they don’t like it. What they’re doing is they’re interpreting that for IDN purposes. So things like dot space, which in our system means I want to search on the name of an object, well, some of the WHOIS clients tend to think that means you’re doing IDN search for an IDN domain name. And they don’t exactly give you – they don’t give us the information that you typed in. So what we’ve done is we’ve added a new flag which does the same thing for the name attribute flag. It’s just the slash. So that should help for that.

Now, as far as the registration service goes: So, as I said, we have a new service that we were going to be working on for registration. What this does, this allows you to go in and to manage the resources you have with ARIN. You can create POCs, create ORGs, change your networks, so forth. So the reason we started this really wasn’t because we wanted to do RESTful. That was not the driving, motivating factor. The driving, motivating factor was basically why we’re doing a lot of other work, which is behind the scenes we have a fairly intensive data model change for supporting things like DNSSEC and proper lame delegation checking. It requires a significant data model change which affects nearly every piece of software we have. And so that has required us to go in and rewrite code that’s been sitting there for – some of it for ten years. So we decided, well, in the process of rewriting all this code we’re going to go ahead and modernize it and go ahead and put in a RESTful service.

And doing a registration service that is RESTful actually builds upon the work we’ve done for ARIN Online and the WHOIS RESTful Web service. So we’re basically borrowing a lot of the components and a lot of experience we have from that. The architecture kind of looks like this. You have a registration on the far right. You have a registration database, which is talked to by a RESTful Web service engine. For any RESTful clients, they just talk to the engine or the server, and that talks – and that does all the necessary functions to get the data into the database.

If you’re doing e-mail templates, there’s one additional step. There’s a template processor which goes in and actually changes the – takes the e-mail template, breaks it down into the proper RESTful calls that are needed, and then there’s a client on that tail end of the processor which actually talks to the engine. This will require the API Key as I showed yesterday. ARIN Online, you can go into ARIN Online and create your API Keys. This is something you would see in other RESTful Web services.

Someone talked to me yesterday about how they managed to get snapshots from their Web cam monitoring their rack onto YouTube using YouTube’s API Keys and there was their RESTful Web service. It’s pretty simple. It’s a standard – if you’ve done RESTful Web services, this is what Amazon and others – it’s the same concept.

You can go into – like I said, go into ARIN Online and create your API Keys. Create as many as you want. You can deactivate them. They are not public information and they are not published in WHOIS. So the only people who see the API Key are you. Right? For template compatibility, what we mean by this is we want you to be able to use those API Keys so you can get your templates into ARIN Online. When you submit a template, if it’s a ticketed request, you can go into ARIN Online and you can actually see it in your tracked tickets section, just like you would a ticket that’s submitted via the RESTful call or a ticket from ARIN Online itself.

The way you would do that, the simplest way is to actually go ahead put the API Key in the template. There’s a line we’re going to add. Line 00. You can put it into the API Key. Now, we realize some people have some problems – it’s not exactly easy to always modify template systems. You can also put it in the subject if you want to or the from address.

And then, finally, we’re going to add a fourth option where you can go into ARIN Online and you can actually explicitly associate a from address with an API Key and ARIN Online. Therefore, you don’t have to modify anything in your template system. The client that we’re using for the template translator, that the template translator then takes the templates and has to use a RESTful interface to actually talk to the engine, that RESTful client we plan to open source.

We looked at the architecture and we said, well, this is natural this is a separate piece of code. So we plan to open source that code in order to benefit the community.

There is a RESTful API draft at this location. The URL up here. You can go ahead and look at it. We’ve got some basically templatey calls, and we talked about how the registration service will work. And that is it. Any questions?

John Curran: No questions for Andy? Okay. Let’s see. Okay. Good. Thank you, Andy.

[Applause]

We’re getting ready for our first policy proposal. Couple of housekeeping agenda items. One is – Andy didn’t mention this, but as part of deploying this system of the new API interfaces and RESTful interface, we need to rework a little bit about how authentication is done, obviously, through this process.

One of the things that we’re having a little bit of a challenge with is trying to handle one of the validation methods we have for e-mail coming in.

As people know, we support PGP. We support flat e-mail passwords. We’ll be able to do so and add this RESTful interface for templates. Anyone in the room use ARIN’s X.509 interface for securing your templates? If so, raise your hand. Anyone in the room know anyone in the room who uses ARIN’s X509? If you know that person, send them to me. We actually have a short list. I can accomplish it in about two hands. We’ll be contacting them. We’re looking at the tradeoff of trying to maintain that through this transition. And it might not be cost effective given the widespread support of X509.

And so I just want people to know they’ll see an announcement about that as we roll this whole thing out, but I wanted to first double-check if we wanted to discuss it here. But I see that’s probably not necessary.

Wonderful. One other thing. I know a lot of people were at the social last night. And everyone had a good time. And someone came back from the social but left their bag there. We have a black rucksack-style bag, Swiss make, which we’re holding on to. It has stuff in it. If it happens to be yours and you – you got it? Okay. Very good.

I wanted to make sure someone found their home because it was going to end up being one of our next gifts on one of our drawings. Okay.

That covers all of our announcements. I think we’re getting pretty close. We’re within three minutes of 10:00. I think I’m going to start the policy discussion.

The next policy is the Simplified IPv6 Policy, Draft Policy 2010-7, and let me do the introduction of this and then I’ll have Scott come up and go through the AC presentation.

Draft Policy 2010-7: Simplified IPv6 policy

John Curran: Original Policy Proposal, 29 December, 2009. As Scott will explain, that’s this incantation of this particular thought. It actually has a longer pedigree that he’ll probably go into.

But AC picked it up as a draft policy on the 23rd of February. The shepherds are Dave Farmer and Scott Leibrand. It’s a significant change to IPv6 policy. The goal is to simplify and create a more understandable mechanism which still recognizes the need for different organizations of different sizes to get addresses but doesn’t cause routing table bloat.

The organizations will be allowed to qualify for one each of the following prefixes: /48, /40, /32, /28 and /24. Qualification for each prefix would based on the specific requirements: multi-homing, host count, number of sites, and number of projected /48s. Each prefix is issued in a specific range. So you would know that a given prefix was issued by ARIN out of that particular range.

Draft policy is most certainly unique to the ARIN region right now. Other RIRs have IPv6 assignment allocation policies that are similar to our existing structure.

Liability risk: None.

Staff comments, issues or concerns: No. It’s fairly clear what we would be doing in this case. And the resource impact would be minimal.

PPML discussion: Of this version, three posts by three people. Two in favor; zero against. One thing saying I support the policy. A question about the policy regarding whether or not it would allow someone to reserve a portion of their /32 for residential clients and then SWIP the entire range, which is sort of an orthogonal question. We didn’t have much discussion on the list of this policy proposal.

So that’s the introduction of it. I’ll ask Scott to come up and lead the AC presentation.

Scott Leibrand: I think John just didn’t want to go through all the old threads. There’s been a lot of discussion of this over the history of many different policy proposals.

So while waiting for slides: This policy proposal, I’ll go ahead and do the history first because that’s somewhat interesting.

There have been a couple of different policy proposals from Bill Herrin that do things similar to this. The most recent one was Policy Proposal 103 – I’ll go out of order here – that Bill Herrin proposed in November 2009.

Dave and I, the shepherds, observed support from a significant section of the community to revise v6 policy in some significant way but couldn’t find support for 103. So that was abandoned by the AC.

This proposal was written to incorporate ideas from that and from elsewhere on PPML. So I really can’t claim that these are my ideas, because they’re not. So thank you very much, Bill.

Going back to the beginning, there are three policy proposals here that we will be discussing over the course of the next few hours. Yes, they are somewhat mutually exclusive. They are different alternatives to doing things.

In particular, 2010-7 is mutually exclusive to the other two because it basically rewrites and simplifies the entire IPv6 policy. So bear that in mind as we have this discussion; that there are a couple of different alternatives here, couple of different ways we could go. So think about that.

David will be doing the presentations after me on -8 and -4. So what are the differences?

The one that we’re about to talk about is a comprehensive rewrite and simplification of the entire v6 policy. -8 is a rework of just the v6 end user assignment criteria: removes host counts: does some other things.

-4 is a rework of the v6 allocation criteria for ISPs. So the proposal we’re about to present integrates allocations and assignments. The other two leaves them separate and addresses some various issues with them.

So what are we doing here and why? So, current v6 policy is long and complicated. I don’t know when the last time you guys read through the entire v6 policy. But there are a number of different pieces that interact in a number of interesting ways.

That’s because this v6 policy was put together as a global policy when v6 was first around. And kudos to the people who were doing this a lot longer than I have been and made that happen.

They didn’t have a crystal ball. They didn’t know what was going to happen with v6 deployment. There’s been a number of things that have happened since then; a number of additional sections of policy that have been added since then.

There’s some complexity as a result of that. There’s a lot of v6 addresses. But we’ve never felt comfortable making them completely freely available, because we recognize that that has impacts on the global routing system.

And as much as we want to say routing is not policy, addressing policy has to be cognizant of routing. So that’s one of the things we are keeping in mind as we put together revisions of policy and as I attempted to try and rewrite policy.

Okay, went through the history stuff. So what does -7 do? Deletes a bunch of historical and duplicate stuff. It deleted a lot more stuff, but that was stuff ARIN was already taking care of. They made a number of administrative edits to the NRPM that have simplified the v6 policy considerably already or this would be even more rescission.

It removes the HD-Ratio. Dave Farmer’s grandma cannot understand HD-Ratio. Several people’s lawyers and business folks – HD-Ratio is math. Math is hard, let’s go shopping.

[Laughter]

Seriously, though, there are a number of people who basically said why can’t you write this in English. So what we did was we took the numbers out of the HD-Ratio, made them the basis for policy, and then eliminated the complicated logarithmic table that a number of non-math people didn’t understand.

Unifies the criteria for allocations and assignments. They are somewhat different, but in v6 there’s a lot of question as to who gets an allocation and who gets an assignment. If you’re an ISP, you get an allocation. If you’re a big end user, then you say I’m going to be an ISP and LIR for all of my departments. And you get an allocation. There’s a lot of confusion there. So this proposal attempts to integrate all that into a single unified set of policies so that everyone can get the appropriate size.

And whether they get an allocation or an assignment is more of a function of whether they do SWIPs and whether they pay the allocation of the assignment fee schedule than a matter of policy and how much they qualify for.

It creates size classes. So as was mentioned on the intro slide, there are a number of discrete sizes, mostly separated by eight bits, one byte apiece, that make it so that if you have a very small need you get a 48. If you have a little bit bigger need, you jump to a 40. A little bit bigger, jump to a 32. That simplifies the criteria immensely.

Either you’re big enough to get the next size block, which is fairly straightforward, or you’re not and you go to the smaller block. It also means if you’re big enough to get a 47, then you qualify for a 40 pretty much automatically.

I like this last bullet point. Reduces v6 policy from 11 pages to four, from 3,660 words to 1,010 words.

Yes, this policy has got some length to it, but it’s got a lot less length than the current policy. So we’re going to have to wrap our minds around it and whether it makes sense. But I’ve recognized in the past that long and complicated policy is not good. So this attempts to simplify it quite a bit.

This classful stuff: Why in the world would we want to change from what we’re doing now to that? The basic idea here is that there are a number of enterprises, ISPs, end users, of all sorts who would like to be multi-homed, would like to get address space from ARIN.

If everyone who wanted address space from ARIN got it, there are some people who are concerned that would create too many routes.

So sort of in exchange for that, this policy provides a safety valve. If there become too many routes because too many people get on the Internet with PI space and were too successful, this allows for safe filtering of traffic engineering deaggregates.

If you get a 32 from ARIN and you announce a bunch of 33s, 34s, 35s, 36s for traffic engineering, your upstreams need to hear those. Your peers need to hear those.

The guy at the other end of the world can probably get away with your 32. If he knows that that 32 is what he needs, he can safely filter the other stuff.

If he has to go look in WHOIS for each and every one to figure out what is safe to filter, he’s probably not gonna.

But if he can do it by simply saying: I’m going to accept all 32s out of this block and I’m going to filter everything longer than 32, he can safely ensure reachability while getting rid of the traffic engineering deaggregates that he doesn’t need to see.

It also expands the availability of nonrouted blocks for internal infrastructure. That is to say, current policy allows in very limited circumstances for someone to get a second block for stuff that needs to be completely disconnected. The policy was designed for networks that need to run it on their backbone and not have it reachable.

But if we’re going to be making routable blocks very easy to get, there are a number of other people out there who would like to be able to get non-routable blocks. There’s been extensive discussion on PPML as to why that might be the reason, but we don’t really need to get into second-guessing people’s networks and what they need. There are people who need it. I believe we should make it available.

So we can go through specifics of the text, but you have that in your packet. We’ve done some summary stuff. I anticipate a lot of discussion on this. So let’s go to it.

John Curran: Microphones are open for discussion.

Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. One of the concerns I have with this is that it creates, in addition to the convenient way you can filter things out based on is it a TE route versus the original whole prefix, is it also creates a convenient way you can filter things out based on is this a small ISP or a large ISP or an end user. And I’m not sure that that’s a good thing.

John Curran: Owen, given that circumstance and the fact that it might not be a good thing, are you in favor or opposed to the policy as written?

Owen DeLong: I’m not completely sure, but my general tendency is to oppose it as written at this time.

John Curran: Okay. Thank you.

Center rear mic.

Aaron Hughes: Aaron Hughes, 6connect. I just wanted to respond directly to the whole TE thing. Today in operational practice the announcer is in control of the routes. Use a lovely thing called communities and a noexport tag.

It is not up to other people in the global Internet to decide whether they want to take or accept certain routes. It’s going to be a real pain in the ass and break the Internet.

John Curran: Back to the mic, Aaron. You need to go back to the mic. So given that this provides safe filtering of TE traffic, and we know it does, does the fact that someone might do that mean you’re against the proposal, or as written would you be in favor?

Aaron Hughes: I haven’t actually had a chance to fully look through it. The TE stuff I completely reject. The different sizes of v6, that’s probably an interesting thing to talk about.

There’s certainly some things in here that look like they’re reasonable for a new v6 policy as a whole. It is certainly going to be difficult to get all of this stuff passed in one shot.

John Curran: Thank you.

Far left microphone.

Tony Hain: Tony Hain, Cisco. I oppose the policy as written. Primarily my issues are around specifying the block sizes as I don’t think that’s really necessary.

I do applaud the attempt at simplification and the overall effort in terms of making life better. I don’t think you need to go to those specific numbers and tie it to TE as the basis for those numbers, because I don’t think – I agree with the previous comment, that that’s not necessary here. Let’s not go there.

John Curran: Okay. Thank you.

Center rear mic.

Andrew Dul: Andrew Dul. The question I have is two questions: one is about sparse allocation, and the other is about international or other RIR cooperation.

The original IPv6 plan was intended to be not a global policy but a global coordinated plan so that we all were generally doing the same thing so there wasn’t RIR shopping going on. Has there been any attempt to work with the other RIRs to harmonize this idea, or are we going off on our own?

Scott Leibrand: Basically we are not sure if this is the direction we want to go. If we do decide to go in this direction, yes, we will definitely be working with the other RIRs to determine whether and how far in this direction they want to go as well.

I personally do not think that we ought to try and make this a global policy because nothing will ever happen. But I do think that if we start in this direction, we definitely need to globally coordinate it as much as feasible given the other RIRs’ differing needs and what they want to do.

Andrew Dul: But nothing has been done at this time to discuss this in other regions?

Scott Leibrand: Correct. This is the first discussion of this idea in a public policy meeting.

Andrew Dul: The other question is whether this policy changes the idea of sparse allocation that is intended to be done with IPv6. I don’t know if we actually started doing sparse allocations yet. That was a question we had a couple meetings ago.

John Curran: We have started doing sparse allocation.

Andrew Dul: Excellent. I’m happy to hear that we’re doing sparse allocation now.

John Curran: This would require us to do sparse allocation against a number of buckets, obviously.

Andrew Dul: So the buckets would then be smaller, though, right?

John Curran: Yes.

Andrew Dul: Thank you.

John Curran: Andrew, given the answers to your questions, the fact that you’re more fully informed, would you be for or against the policy as written?

Andrew Dul: I do not currently support the policy as written.

John Curran: Thank you.

Far left microphone.

Marla Azinger: Marla Azinger, Frontier Communications. I don’t support this policy. Classful routing is history repeating itself, and I don’t believe we should do that. I think it’s smart to learn lessons from history.

There’s other things in here, as I go through here, too. You don’t have RWHOIS in here. And I believe you need to add that in there. Specifically 6.3. So –

Scott Leibrand: 6.3 is copied from existing policy. Yes, there are some changes we could make. I did not want to try to and do more than I had to.

Marla Azinger: You already did that, so go for it.

[Laughter]

Also, I don’t like the – I do like how you put in examples of what you can do for addressing, but I don’t like how there’s dictation as to subnet sizes in here.

I believe justification should stand on its own without dictating subnet sizes, what certain assignments should be. Because it does address in here what I’ll give my end users should be like a 64.

If I decided to give them and route them as something even more specific than that, then I should be able to do that. It’s not within ARIN’s charter to be writing routing policy right now. I understand we could change it. But there’s a lot in this proposal that is routing policy. And it doesn’t belong.

Scott Leibrand: Can you point me to which part you’re talking about?

Marla Azinger: Yeah.

Scott Leibrand: Are you referring to what’s up in the middle of the screen, slide three?

Marla Azinger: There’s examples right after it. But it’s Section 6.3 I believe had some of it, and then the next one, 6.2.

Scott Leibrand: 6.2.2 is on the screen in the center there and has the 6 to 4 for only one subnet. Is that what you’re referring to?

Marla Azinger: There’s several. I’ll give them to you because I don’t want to hold up the line, because my points got across. But I’ll give you the specific line items.

Scott Leibrand: The reason I’m having trouble remembering what you’re talking about is because I think all the stuff that you’re talking about referencing specific subnet sizes is copied from the existing policy. So –

Marla Azinger: If that is true, I obviously don’t agree with existing policy.

[Laughter]

John Curran: Thank you.

Far right microphone.

Joe Maimon: Joe Maimon, CHL. I do support this proposal. I do also recall the earlier threads. They were a lot more wild than this one here.

And I do want to address the TE aspect of this. I don’t believe that just because you want to do TE and I have no discernible way of detecting it that I’m then left with the choice of breaking my Internet or taking the world’s TE.

Barring any polite way to tag a route that’s echoed globally around the world that this is a TE route, feel free to ignore it if you really must, it’s up to policy to try to help people out.

However, it’s quite possible this is a little bit too late. I mean, has anybody done an exercise to see what would a prefix list actually look like based upon the complete IPv6 allocation history? Is this kind of change just too late to give somebody a nice, clean list?

Scott Leibrand: If you’d like a short answer to that, no, I haven’t looked at every historical everything, but the idea in my head is v6 is still fairly new, and if we grandfathered everything that’s already deployed out there and started doing prefix lists on these new buckets, that by the time we were actually required to do something to limit the growth of the table, I believe this would not be relevant.

Joe Maimon: Thank you.

John Curran: Thank you.

Center rear.

David Williamson: David Williamson, Tellme Networks and Microsoft. I think I’m hesitantly in favor of this proposal. I think it might need one more round of refinement.

The classful aspect of it is kind of interesting. I generally agree with Marla that repeating history is bad. But it’s not clear it’s necessarily a complete repeat. It’s definitely buckets, but it’s not quite as obviously limiting as the ABC routine.

One of the things with the buckets, though, that was almost addressed there, what happens with existing assignments and allocations? Is there intent to bump them up to the next largest bucket size? Because I can see a future where as FIBs run low people start filtering. If you don’t fit one of those buckets, you get filtered out. And as a holder of a /45, that’s kind of a concern.

Scott Leibrand: So the intent was not really to touch anything with what’s already been given out. However, there’s a possibility that ARIN may be reserving a block large enough to bump up your 45 to a 40 at some point.

If that’s not possible, any TE filters that could be made from this at some distant point in the future would be made on specific blocks specifically assigned to the purpose. Your block is not – your block is not in one of those blocks.

John Curran: You’re not in one of those.

David Williamson: So we’re expecting if we do adopt this, all future assignments or allocations or whatever term that’s going to be used for this unified environment will come from new blocks that are currently entirely fallow suite, have created a swamp?

John Curran: We tried to make one of those blocks have a 192 in it just so you could know.

David Farmer: David Farmer, University of Minnesota, ARIN AC. I just wanted to comment. We could probably also put in some mechanism if somebody wanted to trade an old block in for a new under the new schema. It’s not there right now, but it would make sense.

John Curran: It would be easy to add something to allow someone to trade into one of these blocks if necessary but not contained in the current proposal.

Far right microphone.

Dan Alexander: Dan Alexander, ARIN AC and Comcast.

I agree this does simplify the wording of the proposal or the policies quite a bit, but it also changes a lot of the models quite drastically.

In my day job I have to manage a lot of address space and I’m always getting hit by different groups trying to implement routing policy in how we allocate address space or incorporate security policies or applications and different services. And everyone’s always trying to categorize things so they can manage their world a little easier.

And historically I think one of the advantages of ARIN has always been is ARIN basically doesn’t get involved in all that and it’s left up to all of us as we manage our networks on the edge, the agreements that we work out amongst ourselves and so forth.

I’ve noticed in the conversations lately, whether it’s this one or it’s GUA versus ULA, and we’re talking as a community in a lot of ways how do we offload some of the day-to-day management or how do we incorporate some of the policies and kind of hand those off to ARIN and let them manage it, which that concerns me because it adds an awful lot of overhead to ARIN that I don’t know if we really as a community would want them to get involved with.

Because we’ve got a lot of situations here where we like to say, well, we’ll park this block for this special purpose and we’ll let ARIN manage that. But as we all know, when we get the business people involved, a lot of our engineering plans go right out the window.

And when things start being used for different purposes, are we going to then turn to ARIN to try and enforce that somebody else broke the rules or didn’t live up to our expectations as far as how this policy is managed, and I don’t know if that’s a road we should really be going down.

John Curran: Okay. You can go back to the mic. It’s right there. So –

Dan Alexander: As the policy is written, I’m not – I’m not opposed as if this should go away, but I’m not in favor of it as written.

John Curran: Thank you. Okay.

Far left mic.

Marla Azinger: Marla Azinger, Frontier Communications. The part about someone said, well, we can just renumber them and give them another larger block. This is v6. I’m sorry. But I am not going to renumber my network.

I am doing that like crazy right now with v4, and I am one of the ones that always stands up and says, yes, it’s possible and you can do it, quit whining, because that’s the situation we’re in with v4.

But, by God, if we can do the right thing with v6, let’s do the right thing and not say, oh, if you happen to use up this 32 and they didn’t leave room on that for you to grow, I don’t want you telling me “I’m sorry, you weren’t in this classful section we just made over here, so you’re going to have to renumber your whole network and all the eyeballs on your network to the v6 block.”

I’m sorry, but there’s no way I can support that. My customers are the ones that are going to pay for that, not just me. And it’s hard enough with v4.

When they look at the hex, their eyes are going to go like behind their heads and say “What do you mean this is what we have to renumber again?” It was bad enough for them the first time probably when we had to get them on v6.

So renumbering, I would really hope that everybody understands that that should not be a topic or a method that we go about using.

Scott Leibrand: And is not in this policy.

Marla Azinger: Right. But it came up. Because you’ve got the classful routing in here, it can happen.

John Curran: Point noted. I think it came up as a voluntary mechanism. But, Dave, do you want to respond?

David Farmer: David Farmer, University of Minnesota, ARIN AC. I didn’t actually say renumbering. I said they could get another block. That’s part of the new policy.

John Curran: That would need to be made very clear.

David Farmer: Yes. I was saying that there are options to fix this if we think that’s an important fix.

John Curran: So noted.

Center rear mic. I’ll be closing the mics shortly. Before you speak, two things. I’m going to be closing the mics shortly. If you’re going to get in line, get in line now.

One of the – if you’re at the head table and you want to speak, I need you – because everyone’s leaning over their keyboards, I need you to lean backwards to get my attention.

Thank you. Okay. Go ahead.

Wesley George: Wes George with Sprint. In general, I don’t support this policy as written. Not saying that it’s a bad idea all the way around, but there’s enough concern with the way it’s currently written that I think it probably needs another round.

In the interest of giving you some more specific feedback, just to sort of respond to Marla’s earlier comment about learning from history, I think that is an overly simplistic view of it. I’m not saying necessarily we want to go back to classful, but we didn’t abandon classful because it was a bad idea. We abandoned classful because we ran out of addresses.

So I think if we’re going to go back in that direction, what needs to be very clear is what benefits we expect to see from going back towards a classful allocation scheme versus staying kind of with the current set of primarily classless. So that would be one of the things I would think needs to be clear on this.

And probably what – there’s some truth to that you’re not going to get this approved all at once. There’s probably some places you can separate this out. Because I think there’s a lot of value in splitting out or redoing the language to eliminate a lot of the HD-Ratio stuff.

That’s one of those things, it could almost be its own separate policy that would get support a lot quicker, I think, and would kind of – that’s one of the easier things. When we start talking about going to a classful versus classless, that’s something that’s going to end up taking more debate.

The other thing that I think is kind of missing in the classful and filtering discussion is that deaggregation isn’t just about TE. There’s also things like – I mean, now, granted, there’s a lot of other things that factor into this.

But if I as an ISP get one of these blocks and then want to allocate to my downstream customers, there are some of my downstream customers that are going to want to multi-home.

And if the assumption is, well, this is all TE, we can filter all of this, what that essentially does is break multi-homing in the way that it currently works.

Scott Leibrand: Right, which was a serious concern discussed on PPML. And basically the bargain here is that anyone who thinks that PA multi-homing is insufficient because of the potential for filtering can get PI space.

This would be different from the current system in that multi-homing with BGP more specifics would probably be not as preferable as multi-homing with BGP and PI.

That is a significant change, and I’m not sure if it’s a good thing. I know it’s a good thing for some people and a bad thing for other people. I’m not sure how those break down.

Wesley George: I think that’s more the point I was making; it’s not necessarily that it isn’t covered in here, there’s just about three or four different proposals that cover pieces of this. And it’s hard to throw them all together and figure out how it’s actually going to change the policy. Because they all kind of are talking over the same space.

So that’s part of the issue. The other thing is that I’m trying to understand better why we want to allow for multiple allocations to the same entity of different sizes.

Scott Leibrand: So Marla doesn’t get mad at us making her renumber.

Wesley George: Is that the only reason?

Scott Leibrand: Basically – currently, the only way to grow in v6 is to hope that ARIN has reserved a big enough block for you to grow into. The way to grow under this scheme is keep your existing block, get a second one. At the very most you’ll have a couple, three blocks that you’ve done if you have a humongous growth path that goes from really, really tiny ISP to really, really humongous ISP over the course of years.

Most people are going to have at most probably two blocks because, unless they’re stupid, they’ll get a block that’s fairly good sized to begin with and maybe grow into one more.

Wesley George: I’d rather see there be some constraints around that. Because there is potential for an awful lot of additional slots going into the table, where if – with a combination of slightly less restrictive requirements. So if you think you are going to grow, you can get a bigger block to start with.

Scott Leibrand: That’s totally the idea here. Looking at this thing, if you are an ISP and you need slightly more than a 32, you don’t get a 33 – or a 31. You get a 28. A 28 is many, many times bigger than a 32.

If you are crazy growth and you get past that, then you’ll get a 24. These are four bits, but that’s 2 to the 4 more addresses.

Wesley George: I’m following that in terms of the differences in the sizes. What I’m saying is I would rather see some language in this that if you’ve had to get more than two different blocks, it might be time to think about getting one large block that aggregates the whole mass.

Scott Leibrand: You can’t get two small blocks.

Wesley George: I’m not saying two small blocks. I’m saying, let’s say, a small and a medium. It may be time to look at let’s aggregate that into one and eliminate some of the table bloat that comes as a result.

Scott Leibrand: That aggregation is encouraged but not required in this policy.

John Curran: I’ll be closing the microphones. Microphones are closed.

Final comment.

Kevin Oberman: Kevin Oberman, ESnet. I’ve been trying really hard to wrap my mind around this proposal because it’s so big, so complex, and handles so many things. And for that reason, and simply that reason alone, I’m opposed to this policy as written.

It is just trying to do too much at once. As previously stated, various pieces could be handled independently, because they truly are independent.

A general cleanup is a good thing, and I think that would be absolutely wonderful, because I think this desperately needs cleaning up. But combining it with things that are very independent pieces, like the lovely HD-Ratio. And, yes, I would love to see that as a separate proposal, because as it now reads people just go glassy eyed when you start talking to them about it. And I’ve tried and it just doesn’t work.

Also, I think that as far as cleanup is concerned, you neatly managed to avoid some of the areas I most wanted to see cleaned up. That’s just the way these things work when you try a massive cleanup.

Scott Leibrand: Please submit a policy proposal; I’ll be happy to help you with it.

Kevin Oberman: I’m seriously considering doing it. I’m just saying I think we need to look at breaking this up into some slightly more manageable pieces.

Right now I think it is just too big a step to take in one big bite. The debate will go on forever. And that’s why I’m opposed to it as written.

Scott Leibrand: John, may I make a couple of comments before –

John Curran: Yes. Thank you.

Scott Leibrand: I’ve been trying to save a couple of the larger comments. Two things: Classful is – this is not classful routing. This is classful addressing. A lot of issues with classful routing are well known and whatever. This is a different candle of wax than we had before. It’s a subset of it.

There are a number of benefits. There are a number of drawbacks. We’ve talked about those. You can all understand. But please don’t be afraid of this because it’s going to take us back to classful routing. Of course it’s not.

Much of the justification for going to classful addressing centers around this tradeoff between giving a lot more people the access to PI and giving us a safety valve of TE.

I do not expect anyone to be filtering TE deaggregates anytime soon. We heard from Geoff yesterday that we’re on a growth path of 10 percent per year growth in addresses. And his guess is that we can handle 20 percent per year growth before we need to filter anything.

That quantifies what has been my intuition for a while, which is we’re not really that close to the edge right now.

I believe we can be a lot more liberal and allow for a lot more growth of the Internet by liberalizing our allocation and assignment policy.

At some point we need to have a way to deal with that, whether it’s ID load split, whether it’s something else, or whether it’s this ability to do filtering of TE deaggregates if you really have to. I don’t anticipate that anybody’s going to use this in the next five, probably even ten years.

But if we’re going to make a policy that’s going to stick around for a while, and there’s a possibility something has to happen, I’d like for it to be doable with less disruption rather than more. So I understand people are kind of reticent about filtering TE deaggregates. So am I. I hope we don’t have to do it. This is really just a safety valve.

John Curran: Thank you very much, Scott, for the presentation.

[Applause]

Okay. We need to provide some input to the AC. So I will ask the tabulation machine to get ready. I see one. I see two. I see three. Good to hear.

We’re going to provide some input to the AC by asking for a show of hands on this Draft Policy 2010-7, the Simplified IPv6 Policy.

I’ll first ask for a show of hands in support and then a show of hands against advancing the policy. Everyone should raise their hands for one or the other, but not both.

And at this time I will call the first one. Everyone in favor of Draft Policy 2010-7: Simplified IPv6 Policy advancing, raise your hand now. Nice and high.

Okay. Gotta allow that to get out to the remote participants because they get to participate as well. We’re good. Okay. Everyone opposed to Draft Policy 2010-7: Simplified IPv6 Policy raise your hand now. Nice and high. Nice and high.

Okay. Thank you. They’re doing the tabulation now. People have finally realized that if you take a popular position your hand has to stay up longer because we have more to count. But that’s okay. Feel good, because you’re in a popular spot.

They’re doing the tabulation now. Following this on the agenda is the break. I’ll do some notes for that. I just want to say – yes, take a break. We have our Info Center out there. You can see the presentation and the materials that we provide when we do trade shows, when we go and speak at conferences.

We also have – that’s the lunch table. I’ll skip that. We also have for one – for the slide booth out there, there’s a little character in there. Has a nice little face mask. We’re trying to name him: a little contest and a bowl. You can suggest names for that gentleman.

And we’re going to come back here promptly. We’ll be back in here very promptly at 11:00. So we have about 22 minutes for the break. Okay.

On the matter of Draft Policy 2010-7: Simplified IPv6 Policy, number of people in the meeting room and remote, 136. In favor, three; against, 50. This will be provided to the AC for their consideration. I thank everyone for participating.

Draft Policy 2010-8: Rework of IPv6 assignment criteria

John Curran: Original Proposal 107 submitted on the 14th of January. Accepted by the AC as a draft policy on the 23rd. The current version is the April 5th version. Shepherds are David Farmer and Scott Leibrand.

Summary: End users, including private networks, may request a /48 for each site in their network. Criteria must be multi-homed or have an existing IPv4 assignment or provide technical justification and a one-, two-, five-year plan status.

Policy is only in the ARIN region but it does have implication to policy in other regions. AFRINIC, for the IPv4, have a plan. APNIC, you automatically qualify for IPv4 space, else you have to plan a multi-home. LACNIC, automatic if organization has IPv4 space, else have a plan and route the aggregate. RIPE NCC, multi-home and sign the contract.

So staff assessment. Liability risk: No liability risk. Comments or concerns: Yes. It has very specific criteria for assigning a site more than a single /48. It makes it easier to understand and provides the necessary details that have been missing. So from that perspective it’s good. It relaxes the current qualification criteria for current /48 and opens up the policy pretty much to everyone.

It could significantly increase the number of assignments we make each year. That has staffing implications, but if we make it easy enough, hopefully we won’t be impacted from that perspective. That’s why it says minimal. It does have a conservation question, though, because obviously if we’re making lots of assignments, we have to make sure we’re doing them with the right level of assessment of concern and conservation.

PPML discussion: 24 posts by seven people. This was on the proposal when it was submitted. Two in favor. Two specifically in favor. One against. “I just want enough address space to number all my facilities in their own /48 without having to do the ARIN dance every time I add a new one.”

“2010-7 is superior to and incompatible with this proposal. I strongly prefer the 2010-7.” Which we considered earlier.

“I’m concerned about assignments to non-connected networks where qualification is based on the promise that they won’t ever connect to the Internet and therefore won’t introduce a route into the IPv6 backbone.” Obviously multiple sites all with their own prefixes will end up potentially being distinct routes.

Okay. At this point I will ask Dave Farmer up to give the AC presentation.

David Farmer: David Farmer, University of Minnesota, ARIN AC. So as Scott mentioned at the beginning of 2010-7, this is taking a different tact at revising IPv6 policy.

This proposal is limited to the assignment criteria section. Kind of along some of the feedback we got from the last proposal, that’s kind of big. This is a little bit smaller. Might still be too big. I can understand that, but you can see where it’s definitely a smaller scope. So the problem is that current IPv6 criteria are based on IPv4 policy. This creates a level of indirection that confuses a lot of people.

I forgot to check the slides for how this animates. So this is the current direct assignment criteria text. Not a lot there. Pretty terse and basically references you if you can get IPv4, whatever terms you can get under, get an assignment from IPv4, you can pretty much get it for IPv6.

Some additional – so basically with 6.5.8.1, which is that previous chunk, and 4.3.5, it seems you can get non-connected IPv6 for non-connected networks. However, 4.3.5 references RFC 1918, not about IPv6. And this is confusing. And I’ve had people argue varying opinions on this with me, whether that really is the intended case or what it says.

So I would have to say host counts, which are what basically IPv4 policy is based on, seem irrelevant in v6 when you have 18 times 10 to the whatever there hosts per subnet. And multi-homed end users are going to likely use a routing slot regardless of their host count.

So what does it do? We replace 6.5.8 with new language. We rearrange 6.5.8 putting the initial allocation first, followed with criterion for making the allocations. This little tweak and change allows for an easier way to add new criteria in the future if we ever wanted to do that without renumbering or rearranging things in the future.

It moves the 6.5.8.3 subsequent assignment size to 6.5.9 calling it Subsequent Assignments. This is to enable that adding of future chunks. In order to make room to do that move, it moves community networks to 6.5.10. In the future, we could maybe make that new criteria for an assignment and put it all under there.

There were some objections to doing that in this, mostly around the “how many things are we going to do at once” kind of thing and that community networks is a relatively new policy, let’s not muck with it just yet. You’re going to have to evaluate whether it’s clear or plain language, but I was at least attempting to write this in much more clear English rather than ARIN-ese or techie-ese.

So here’s where – so for end users with multiple sites, allows up to a /48 per site. Really do want to talk about this concept. This was the feedback that I got on the PPML where people would want to go. There weren’t a whole lot of arguments to the contrary, so that’s what I came up with. Based on that concept, basically site is equal to a location, not site equals an organization, where we’re kind of at right now.

HD-ratios apply, for the most part, to a single location then that could somehow need more than a /48. That would be an awfully big building, I would think, or an awfully big single location. So it essentially takes HD-ratio out of it for the most part, for everybody’s day-to-day stuff.

So it allows Internet connected end users that meet one of the following criteria to get a minimum allocation of /48 or larger. They can – if they have a previous IPv4 allocation, so if you have v4, you’ll need to get v6, or are immediately becoming v6 multi-homed.

There was a question about, well, should it apply to v4 multi-homed, et cetera, et cetera? If you’re v4 multi-homed and have a PI or your own allocation, well, then you kind of fit under the first one.

If you’re wanting to – if you don’t have an allocation from ARIN and are wanting your own v6 allocation, then you should – the idea here is you should have to be multi-homing v6 in order to get to that point. Or you can provide other technical justification indicating why v6 addresses from an upstream ISP or some other LIR aren’t suitable and provide subnet plans and various things justifying your usage.

So here’s, as I said, depending upon your beliefs on how the text reads, non-connected networks are kind of already in there. This is just making this explicitly clear. And then having as part of the justification for getting one, explaining why ULAs doesn’t work for you.

In the actual text for both of these last two pieces of justification, there are some example justifications. I would love – if people have other text they’d want to put in there as suggestions to staff, I’d love to hear those, and I’d be happy to add them.

So some discussion questions I’d like to hear some feedback on: Should we keep host counts? Is the site equal location the right concept to use? Or do we need to go back to site equals organization?

So if we have site equals organization, should something like the multiple discrete networks policy apply to end users?

If an end user has a site on each coast, how should that work? Is IPv6 non-connected appropriate as we’re talking about here? So questions, et cetera. I have the whole text listed here if we need it. But we’ll get it if we need it.

John Curran: Okay. Microphones are open. Questions?

Stacy Hughes: Stacy Hughes, ARIN AC. Would you go back to the previous slide, please, because you’re asking questions and we’d like to answer them. What is “IPv6 non-connected appropriate”? What exactly does that mean, please?

David Farmer: The non-connected networks for IPv6 – I probably should have had an extra word in there – is that an appropriate thing or should we be not – should you have to be connected to the Internet to get addresses? How do we want to deal with the whole non-connected network stuff?

Stacy Hughes: Not connected to the Internet?

David Farmer: That’s my interpretation of 4.3.5. Whatever your interpretation of 4.3.5 for v4 non-connected networks is what I’m referring to.

Stacy Hughes: So I have answers to these questions. Number one, no. Number two, yes. Number three, no. And number four, yes.

David Farmer: Thank you.

John Curran: Based on that, would you support?

Stacy Hughes: I am not in support of this policy as written.

John Curran: Microphones are open.

Center rear mic.

Jason Schiller: Jason Schiller, Verizon, UUNET. I’ll be back up here at the mic later to talk about whether I’m in favor or not in favor. But at the moment I just want to answer the questions. The second question, site, I have actually toyed with the idea of changing the definition of end site. I think location is not entirely correct, because it also has to deal with network topology.

If an organization has 100 locations and they’re all stubs connecting back to a single transit provider, I think it’s pretty reasonable to classify them as 100 sites. However, if those 100 locations are interconnected in a single network, I think it’s fairly reasonable to consider them a single site.

So I do like the idea of site, but I think that we have to be careful with the definition to reflect what the network topology looks like for that site or sites. Given that, I don’t think we need a multiple discrete network policy to apply to that if sites are defined in the way I suggest.

With regard to – is the question should we have a policy about allowing IPv6 addresses for networks not connected to the Internet? Is that basically the question asked?

David Farmer: Yes, that’s essentially it.

Jason Schiller: When I was looking at the internal infrastructure policy, my goal was to make that available to end sites as well as ISPs. End sites can have the need for IP addresses that are not reachable over the Internet, not connected to the Internet.

I don’t see why they shouldn’t be able to play in that space. I think it’s critically important for some people to be able to have globally unique numbers, even though they’re not connecting to the Internet, because they are connecting to some other networks. They are merging with other companies, other organizations. And it’s critically important that they have assurance of no overlap; and in the event that overlap occurs that they can say this space really is mine, you’re the guy that has to renumber.

David Farmer: Before you go away, it’s not entirely clear that the policy that you’re referring to applies to end users. It does have service provider kind of – or provider, something – some language along those lines that could lead you to believe it didn’t apply to end users. So maybe that’s just a simple change we can make.

So for end users that aren’t all part of a common network or that they have some topology that would lead them to, with multiple exits or something like that, or non-connected network things akin to the multiple discrete networks, if that topology is such, is that an appropriate mechanism?

How would you suggest we deal with those kinds of things? So like just a concrete example, an end user site has a site in California and a site in New York and they have different providers; they would like to have their own address space. Should we provide them with a single /48 and they have to announce separate chunks? How do we go about that?

Jason Schiller: Jason Schiller. So if that customer, end site, I don’t know how to call them, if that entity does qualify for address space, because there are two stub networks that are not interconnected, I would define that as two sites, and those two sites would each be eligible for an assignment, if they were both eligible.

Rob Seastrom: Rob Seastrom, ARIN AC and Afilias. Point of order. Would this not be more appropriate for open mic, or if there’s not clarity on the show of hands like yesterday?

John Curran: The question that comes up – we actually, the Board, some of the members of the PDP Committee actually have been discussing open questions from the floor, because certainly there’s an issue there. We really need to – because these questions are up here; I want people to come up to the mic. I want to say whether they support or not support the policy proposal. And if you want to also discuss how these questions make your decision, that’s great. But let’s keep it focused on whether you support or don’t support the policy proposal.

Rob Seastrom: I do not support the policy proposal. And I have nothing more to say at this time.

John Curran: If you change the policy proposal in one of these manners, would it make it acceptable?

Rob Seastrom: No.

John Curran: Okay. Thank you. Far left microphone.

Marla Azinger: Marla Azinger, Frontier Communications. I don’t support it as written. I think redefining the site would be good. But like I don’t want to repeat what Jason said. So what Jason said. And then the IPV non-connected approach, if that’s appropriate, there is v6 private address space which could be used for that purpose, and I know v4 – I was actually the one who did that proposal.

So we did that mainly because there was a shortage of private address space, and that was to really kind of get around that issue. So I’m really not sure if that’s needed with v6. Someone could convince me to change my mind. But right now I’m not really convinced that’s needed.

John Curran: Okay. Microphones remain open. Our remote participants remain open. In our last ARIN meeting, we had numerous questions from the remote participants. In this meeting we have more remote participants but less questions. Making me wonder – well, does the mechanism work? Are they actually out there?

I have all sorts of questions. So remote participants who have a question are particularly encouraged to come forth at this time. Mics remain open. Center rear.

Kevin Oberman: Kevin Oberman, ESnet. Mostly up here because nobody else seemed to be commenting on it. But I do not support the policy as written. I do not support it primarily because of the issue of site location.

This is a very tricky question, because it unfortunately gets into the area of routing, something that ARIN regularly says they don’t do. And, yet, I don’t see how you can define this in a useful and functional manner without devolving into areas of routing.

The term “autonomous system” comes to mind. In its original meeting of long, long ago in the days of, dare I say this, EGP – I don’t really want to go there, but I just had to say that. I’m going to avoid saying RIP at least. But we need to come up with a good definition of location before this can go forward, or good location of what entity we’re talking about. I shouldn’t say location, because that implies things that should not be implied.

And I honestly have not figured out a good approach to it that doesn’t delve too deeply into the realm of routing. But, without that, I can’t support this policy.

John Curran: Okay. Microphones remain open. We’ve heard from many people who don’t support this policy. I’d like to hear from advocates who do support the policy, if there’s some out there who can take to the mics.

Okay. Far right side.

Joe Maimon: Joe Maimon, CHL. As I see it, this policy addresses inequity. Basically if you’re an end user you can get an IPv6 PI, but only if you have IPv4 or – I don’t know why we have to keep forcing the issue back to IPv4. We’re trying to replace it. I think that this policy addresses that problem, and therefore I’m going to support it.

John Curran: Okay. Microphones remain open. Any and all comments on the policy proposal. My remote participants come forth. No questions. I guess it’s just not –

David Farmer: Are you out there?

John Curran: – it’s not a contentious policy, I guess. Final chance. I’m closing the mics for anyone who wants to speak for or against the proposal. Some day I’m going to turn off the Internet connectivity during these discussions, but that day is not today. Final chance. Just the v4 connectivity. Good point.

[Laughter]

Center rear microphone.

Heather Schiller: Heather Schiller, Verizon Business, ARIN AC. As an AC member, I just want to say it would be really helpful to hear from other non-AC members in the room about these proposals.

On Wednesday afternoon we have to go back and discuss what to do about each one. And we really take your feedback seriously. And we can’t do that if we don’t hear from you.

John Curran: Thank you, Heather.

Heather Schiller: Let me just say why I’m saying that. Because on this proposal we’ve heard from four AC members, one NRO member, and two non-AC members. So I would like to hear from more folks.

John Curran: Far right microphone.

Michael Richardson: Michael Richardson, Sandelman Software Works. I spend most of time in enterprise, not in ISPs. I think this proposal addresses a real need as for why you can’t use ULA route random. I will hand you a hex number and I’ll ask you to please tell me without WHOIS who it belongs to. Okay. That’s why we need it.

I’ve been in many organizations where in v4 space on the inside of the firewall we randomly have IP addresses that we do not recognize. Where did they come from? Nobody knows. We have no feasible ways of tracking them down except by essentially running around in airports everywhere.

This is the legacy of RFC 1918, of duplicate address space everywhere. And ULA random is, well, somewhat more unique, is still not tractable or auditable. What would you do if you had ULA-R on the inside of your network running around? How would you find it? Okay?

So this does not address a lot of the uses of it, and there will be a lot of ULA-R provided by CPE devices and Linksys routers and whatever. But in the enterprise context, this policy allows enterprises to get some address space to do something. Whether or not they announce it, I believe being told is a routing policy decision, and we don’t do that.

So I believe anyone who asks that question and is worried about it should immediately sit down. That’s not the policy we’re dealing with. We don’t do that. So I’m not really in favor of this policy because I don’t think it goes far enough. But I’m willing to support this policy because I think it’s a very important first step.

John Curran: Okay. Thank you.

Microphones remain open. Center rear.

David Williamson: David Williamson, Tellme Networks and Microsoft. I’ve been struggling with this one. I generally like end user things since I represent end user sites. My biggest question is: What do you see this doing with multiple discrete networks?

I think to a couple of the points that have already been made, the concept of site or organization or whatever label you provide to the allocation units, is inevitably going to be tied to topology. And somehow breaking away from the routing model is going to be difficult.

But irrelevant of that, there are networks out there that have multiple discrete networks, and where networks are fairly unambiguous in that context. How is this supposed to connect with that?

David Farmer: To be honest, I don’t know just yet. In going from site to a location concept was something that came up on the list and I sort of ran with that. And I’m looking – and I know there’s a lot of opposition to that. So I wanted, you know, what are the alternatives to that? And looking at what we already have in policy, if you’re trying to deal with multiple discrete chunks of an enterprise network, well, that kind of looks a lot like the multiple discrete provider network datacenter-y kind of thing that we already have a policy for.

I’m just throwing things out there to motivate discussion. In fact, just one quick thing: I understand the issue about these questions. What I was really trying to do is motivate some discussion, because we’ve had a lack of it in this meeting.

David Williamson: I agree it’s a hard problem to discuss site, organizational, multiple discrete networks, what does it all mean. You almost inevitably come back to routing, which is unfortunate, because we would rather not.

My organization, for example, has multiple ASs, so it’s pretty clear, since there are independent, autonomous systems, that there are multiple discrete networks, irrelevant of site or ORG. But that may not be common. It’s only just a data point, it’s not data. There needs to be something done to be able to address the kind of broad end user requirements, which I think are pretty much unknown. Now it’s going to be troublesome. They currently want to make this host counts out; they have no utility in my mind.

And, yes, John, I oppose this policy.

John Curran: Thank you.

Stacy Hughes: I have a remote participant. And Heather, it’s a former AC member.

[Laughter]

Lea Roberts, Stanford University. I oppose this policy as written. I think the redefinition of site should be considered, but this policy goes way too far.

John Curran: Thank you.

Center front.

Chris Morrow: Chris Morrow, Google and ARIN AC. Sorry, Heather. So there are a couple of things in the policy that came up. Multiple discrete networks, or like multiple locations, has really not handled particularly well for end sites today. I gave a couple of examples on the list about how I have three or four different sites.

My current company has 200 remote sites that are offices locations. And we like to have the ability to filter with one block and make things simple. So can I get 200 /48s from ARIN, please? That conversation is hard to have with the RIRs. They don’t really want to have it. And we also don’t want to front up and say we’re an ISP. That’s not really our game.

So that’s complicated. And so that should be discussed maybe another way. Oh, by the way, I don’t support the policy. So get that out of the way now.

The other thing is, the whole discussion about ULA really – it adds a bunch of complexity to hosts, routers and networking that doesn’t need to exist. The RFC 1918 thing does it today and people overload the term “non-routable.” Right? These IP addresses, they route just fine. We all just happen to think we do the right thing by blocking with the edge, which we actually don’t do, right, in practice. We, the community, not we Google. Because I make sure we don’t do that, I think.

[Laughter]

David Farmer: You try.

Chris Morrow: We do our best. 90 percent. But the ULA thing, it adds a bunch of complexity, which address should I use when I talk to this or that, how do I know I’m talking to the right thing.

The issue of is it uniquely yours when we had this conversation in – Jason, 2005? 2005 we said this is not unique enough. We need infrastructure space. Our legal department eventually is going to say who F’d this up? It wasn’t me. I got mine from ARIN.

This is a road we should not go down, I think, if at all possible. And IETF kind of shelved ULA, which I think was the right answer, although Tony will probably get up and beat me now.

John Curran: I’m going to close the mics shortly. So approach the mics if you’re going to be in queue. Far right.

Gary Giesen: Gary Giesen, Advanced Knowledge Networks. Let me just start by saying I do not support this policy as written, but I do support the aims of the policy and the intent of the policy. I think the definition of site needs to be sorted out. I actually do agree with Jason that it should follow topology. So it should be the multiple discrete networks versus connected networks.

I don’t think it liberalizes quite enough in terms of who can get address space, but I think it comes close. So I would be happy to comment on a further revision of the policy.

John Curran: Okay. Understood. Closing the mics. Closing the mics. Five –

Cathy Aronson: Cathy Aronson, ARIN AC. Maybe you could close it after I ask my question to the audience.

John Curran: Cathy Aronson, center rear.

Cathy Aronson: Cathy Aronson. I worked for a company where we had huge, huge problems with overlapping subnets of Net10 when we would connect a company to our network or integrate an NMS system or whatever to the point where I had my own registry for Net10.

So I was wondering do other people here have issues like that that would – that would be solved by being able to get unique addresses? I can’t imagine that other people in this audience wouldn’t have a need for unique v6 addresses. So if anybody feels the need to give us feedback that would be great.

John Curran: Would people like to comment on that? Anyone want to comment on the question specifically that Cathy asked: Do you have a unique Net10 registry? Or something similar.

David Williamson: David Williamson, Tellme Networks. More to the point, Microsoft. We’re a somewhat large enterprise that does acquisitions, including, well Tellme. Yeah, there’s collision in 10 space everywhere. It’s horrific. There’s an internal registry for who gets what. Tellme, for example, has a piece of our existing 10 space that’s officially Microsoft sanctioned space. And we have other pieces that are not, and the routing in between them is a mess. And the usual nonsense associated with just IP space collisions.

We’re hoping to never ever have this problem with v6 because we each independently came to the acquisition with our own v6 space. It’s separate. It’s clearly globally unique. Irrelevant of whether we route it together or not, the numbers are globally unique.

Global uniqueness has value independent of whether you actually use it for routing or use it for the Internet or just use it internally somewhere. You set off a nerve because the large corporations like Microsoft – it is just a mess.

John Curran: Center front on the topic of unique Net10 registries.

Rob Seastrom: Every company that I have worked for in the past decade, regardless of whether it’s large or small, has had an internal 1918 space registry, and it’s a pain. Especially when somebody doesn’t know it exists.

John Curran: We’ll take one or two more comments on this particular topic. Anyone else who wants to talk about Net10 registries?

Louis Lee: Louis Lee, Equinix. And the past 15 years, every company.

Michael Richardson: Michael Richardson. The motivation to install IPAMs in the last three companies was for the Net10 registry.

John Curran: Net10 registry comment, Marla.

Marla Azinger: We’re getting sidetracked on that because I think the main question was why private IPv6 wouldn’t work, which that gentleman did answer, which I appreciated greatly. And so thank you.

John Curran: So I guess, Cathy, we have a remote participant as well. The point is, Cathy, you’d be against this proposal because it would create a circumstance that we might have to do it for v6.

Cathy Aronson: Yes.

John Curran: Anyone else want to approach the mics? Mics are closed.

Stacy Hughes: The remote participant is Dale Carder from the University of Wisconsin. Is that a homey of yours?

We do run our own registries and deal with 1918 collisions. It is our viewpoint that 1918 should die with IPv4, unique IPv6 only.

John Curran: So final comments on the proposal.

Center front.

Steve Bertrand: Steve Bertrand, eagle.ca Internet Service provider. Although I like the intent of this proposal, I don’t like just the confusion that the questions up there have. For the host count, I’m absolutely opposed to that whatsoever. The other ones, I like what Jason was saying about coming up with a better definition for that term. And the other two, for now I’m just going to leave alone. I just want to point out for those that don’t like the classful addressing aspect. In Section 6.5.8.2, I believe it’s the second paragraph, is replaced by something worded very similarly, 6.5.8.1, and the last paragraph that states that it should be made from distinctly identifiable prefixes. So that’s already in the existing NRPM.

John Curran: Understood, it’s in the existing one. As written, will you support the intent? Without the changes that you’re talking about, do you support the policy proposal as written?

Steve Bertrand: I do not.

John Curran: Final microphone, Heather.

Heather Schiller: Heather Schiller, Verizon Business. I’m opposed to this policy, because I think there’s something else that’s not quite settled first. Maybe it is. Maybe it isn’t. But I think it has the potential to change. And that is to what level do we accept deaggregation? Because the policy will allow you – in a couple of ways, the first portion will allow you to request up to a /48, meaning that potentially ARIN could allocate or assign in this case smaller than /48s, that they presumably want routable. So today, if the general, you know, boundary for – you’re going to interrupt me, aren’t you?

David Farmer: If I have some bad language in there, I’ll fix that. That was not my intent. My intent was you start at /48 and go up, for an assignment from ARIN.

Heather Schiller: Organizations may request up to a /48. But there’s another – there’s sort of another place for that as well, which is that organizations may request for a /48 for each site in their network. And end sites – I mean, it’s not just this policy. It’s the existing policy, too, which is if an end site requests a /48, today they can obtain a single /48; they have to show justification in order to obtain an additional /48 HD-ratio or multiple discrete networks, right.

But my question is when they’re requesting for multiple different sites, we have the possibility that they might want to announce more specifics of the /48 that they’re getting. And it’s possible, if we allow that, that organizations will choose to take a /48 they have and split the /48 between different sites rather than coming back to ARIN and requesting multiple /48s in order to achieve that.

So to me – and it’s not just this policy, but that part of where that boundary is going to settle out is not quite jelled yet. And so I think that needs to be kept in mind as we’re making changes to the end-user assignment policy.

David Farmer: One of the intents of at least proposing the site equals location kind of thing was to try to push – if you ever thought you were going to need a location, that you’re going to want to announce separately to get a /48 for it and to try to help set 48 as that minimum lower bound without actually setting a policy, which we try not to do.

John Curran: Okay. That ends the discussions. Thank you, David.

[Applause]

Sorry. The head table suffers at the end. Go ahead.

Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. I will echo what everybody said about RFC 1918 registries. Having been a consultant and an employee of several large and small enterprises, ISPs, et cetera, I can’t think of a single one where RFC 1918 has not been a nightmare, headache, whatever you want to apply to it.

I think that this policy is not ready for prime time yet, but I think it’s the beginnings of something that can be a good rework of the v6 policy, and I hope we’ll keep working on it.

John Curran: Thank you, Owen. Thank you, David. Okay. In order to guide the AC, we’re going to –

David Farmer: I’m going to be back up here in a couple minutes, but I can go sit down.

John Curran: You’ll be up in a couple of minutes. In order to guide the AC on doing their job regarding this Draft Policy 2010-8: Rework of the IPv6 Assignment Criteria, I’d like to have a show of hands at this time. So we’re going to ask for everyone in favor of the policy and everyone opposed. And I want people to raise their hands nice and high.

I see our tabulation machine is ready, ready, and ready. Good. Okay. On the matter of Draft Policy 2010-8: Rework of the IPv6 Assignment Criteria, if you’re in favor, raise your hand now nice and high. Thank you.

Okay. On the matter of Draft Policy 2010-8: Rework of the IPv6 Assignment Criteria, if opposed, raise your hand now. Nice and high. Almost there. Thank you.

Okay. They’re busy tabulating that. And in this case I’ll wait for the tabulation. We have enough policies of similar name. And I’d like to finish one before I start the other.

Draft Policy 2010-8: Rework of the IPv6 Assignment Criteria, total number of people, 138. In favor, five; against, 33. This will be provided to the AC for their consideration.

Draft Policy 2010-4: Rework of IPv6 allocation criteria

John Curran: Let me introduce this one. This was Proposal 101. Originated 30 October 2009. Current version, Draft Policy 23rd February 2010. Shepherds are Cathy Aronson and Bill Darte.

2010-4 Summary: This is the rework of the IPv6 allocation criteria. Replaces the existing policy with new relaxed criteria. ISPs and LIRs can qualify for a /32 by meeting one of the three following criteria: have an IPv4 allocation, be multi-homed, or have a plan to connect 50 customers within five years. Any of those criteria. Requests are allowed for private networks; meeting the criteria but not otherwise connected.

Status at the other RIRs. This policy is unique to the ARIN region in terms of a policy currently under consideration. The current policy for /32 at AFRINIC: Be a local Internet registry. Have a plan. APNIC: Be a local Internet registry and have a plan, or be an IPv4 local Internet registry. LACNIC: Be a local Internet registry ISP and have a plan and route the aggregate. RIPE NCC: Be an LIR and have a plan for making use of it.

So staff assessment: Liability risk, no. Issues and concerns: There’s not a clear statement of whether serving other organizations or customers must be external. So this could open up the policy to enterprise customers who would appear to be a service provider by nature of providing services to internal organizations.

The new ISP LIR qualification criteria lower the bar to receiving a /32 which would significantly increase the number of allocations, creating a stewardship consideration to make sure we’re not being overly profligate with address space. Resources impact is minimal.

PPML discussion: 13 posts by 10 people. Five in favor; zero against. People supporting it as written. People noting it’s presently impossible to multi-home using a /44 cutout of a 32. And the proposal doesn’t make sense. I decline to support or oppose the proposal.

A comment I didn’t quite understand but it was on the mailing list so we gave it to you. And of course the question that always comes up of what is an ISP. I think, again, because the policy proposal doesn’t, per se, define known ISP, it does have some leeway to an organization that considers it an Internet Service Provider even if it’s an internal one. This is now time for the AC presentation. I get to welcome David Farmer back up.

David Farmer: So this is essentially the same, a lot of the same text but for ISP allocations. I just want to note that a lot of the issues that the staff had kind of exist in current policy, too. I tried to clarify some of them. I obviously didn’t hit them all. So I definitely want to work on that some more. So the problem statement, the language in the current IPv6 allocation criteria is awkward and not well understood by many.

Multi-homed ISPs will likely use a routing slot regardless of the number of customers they have, if they’re going to be multi-homed. A number of people in the community think the current 200 customer threshold is too high. So what does it do? It replaces 6.5.1 with what I hope to be as more easy-to-understand plain language. Rearranges 6.5.1 putting the initial allocation sizes first again, allowing for these new criteria to be added. I got this – actually; I got this idea for both of these out of LACNIC’s policy and the way theirs was organized.

Come on. Here we go. So it allows an ISP to meet one of the following criteria having an IPv4, as was said. Immediately becoming IPv6 or multi-homed, IPv6 multi-homed or immediately becoming such, and providing a plan for one-, two- and five-year periods, with at least 50 customers in five years.

So then it makes it explicit that an IPv6 allocation can be received for services that are not necessarily connected to the Internet. I’ve had various people tell me that the current policy allows for that or doesn’t allow for that. This just says that it does. But it requires additional justification. In other words, if you’re not connecting to the Internet, it seems reasonable to tell the community what you’re doing with it and why. But examples you might do with it are smart grids, special industry networks for banking, stock market, auto parts supplier, et cetera. Things called COINs and other things that do exist today and maybe other future overlay networks.

The proposal – so we’ll come back. So basically I got the text here. This is just – we’ll just quickly go through it. This is mostly just a rewrite of the current initial allocation size. Changing the wording just a little bit, but the intent is not to actually to change the intent at all.

The criteria are as we said. And let’s see here. We’ll keep flipping through these. I apologize for not checking the animation on that. So is 50 the right number of customers? Would it be useful to include a /40 option for smaller ISPs? This came up on the list and is kind of an idea that would come out of the 2010-7.

So those were my discussion questions. And so time for questions and comments. And I’ll go back to those questions.

John Curran: Sure. People who want to comment on the policy proposal?

Stacy Hughes: Stacy Hughes, ARIN AC. I’m already on record saying that we should have zero barriers to IPv6 for anybody who wants it and who is willing to pay the bill. So 50 is not the right number. Zero is the right number, if you ask me.

David Farmer: I personally would agree with that, but I’m trying to find a number that we can get a consensus on.

John Curran: Right. So would you support the policy proposal?

Stacy Hughes: No.

John Curran: Okay. Thank you. Mics remain open. Far left microphone.

Chris Grundemann: Chris Grundemann. Just a couple of things. I’m kind of an Occam’s razor kind of guy. It seems like you don’t necessarily need the two sections, 6.5.1.2 and 6.5.1.3. I know you’re separating between Internet connected and non-Internet connected. But, really, if you just didn’t say Internet connected in 6.5.1.2 and then added B as a D, it would be a little bit simpler and shorter.

Also, I have trouble with the idea of allowing enterprises to get an ISP allocation. If we want to blur the line, let’s just blur the line and hand out allocations or assignments only for v6.

David Farmer: The original version of this that I was working on had explicit language allowing that. I thought I took it out.

Chris Grundemann: Is that out now?

David Farmer: It’s out now. Staff is suggesting I didn’t go far enough, which I’m willing to work on and think about. But I thought I went far enough. But we have to put some language explicitly saying it’s not allowed. And I guess we can do that.

Chris Grundemann: I was reading the text and couldn’t find it. Maybe it triggered the memory of the old text. And also to the point about 50. So being an existing ISP, for IPv4, is already an open door. If you’re operating today, you can have v6. So that number is zero, right? You don’t have to have a host on IPv6; as long as you’re running a network you can have IPv6.

John Curran: Present policy for IPv6 is if you’re an existing ISP and you have a plan to provide IPv6 services, then yes.

Chris Grundemann: But the plan doesn’t define what’s in that plan, right? Just we want to – we’re going to use IPv6 on our network, so give it to us? There’s no number associated with that, if I recall correctly.

John Curran: Just to make sure I have a question of fact accurate. The policies for an initial allocation for an ISP, an organization must be a local Internet registry, must not be an end site, must plan to provide IPv6 connectivity to organizations and must be an existing known ISP in the ARIN region or have a plan for making at least 200 end site assignments to other organizations within five years.

Chris Grundemann: That’s an “or.” If you’re already a known ISP, you can have IPv6 as long as you’re actually going to use it. If you say you’re going to use it, you have a plan to use it. We’re talking about a /32. We’re talking about tens of thousands of subnets for 200 sites. I don’t think that’s a very high threshold, personally.

John Curran: So I understand you think the policy could be reduced by combining 6.5.1.2 and 6.5.1.3. But that won’t change the emphasis of the policy proposal. So are you in favor or against the policy?

Chris Grundemann: I’m in favor of the policy with the caveat we add the text saying that it specifically is not for enterprises or end users, just so that’s clear.

John Curran: So I understand. Changing it for enterprise, so enterprise is specifically excluded would make you support it. As written, do you support it?

Chris Grundemann: Yeah, I think it’s small enough of a change that I support it.

John Curran: That’s useful. Center rear mic.

Kevin Oberman: Kevin Oberman, ESnet. This one I support as written. Doesn’t mean I like it entirely as written, but it’s a lot better than where we are today, I think.

I think it’s a move in the right direction. On the two discussion questions up there, I think 50 is still too large a number, personally. 50 is, I think, reasonable these days, but our efforts to get our customers to move to IPv6 and implement it have been painful, to put it politely. And I concluded that 50 sounds small and sounds easy, and I think at some point after v4 runs out it will become easy. This week it’s not easy.

I’m not sure that I could favor including a /40 option for smaller ISPs. I’m not sure that that really improves anything a great deal. Potentially adds more prefixes to the DFZ. I don’t see any real merit doing that.

John Curran: Microphones remain open.

Stacy Hughes: Remote participant, Randy Carpenter, wants to make sure that there are provisions for sparse allocation such that if an ISP gets a /32 and they need to grow they can have one announcement.

David Farmer: We could add that to the policy, but that’s more – one could consider that an operational issue.

John Curran: ARIN was instructed to utilize sparse allocation for its IPv6 work where possible. And we’re doing that. So we would do that by nature.

Okay. Far left microphone. I am closing the microphones shortly. Anyone who wants to speak in favor or against the proposal find a microphone soon. Far left.

Dave Barger: Dave Barger, AT&T. I’m in favor of this policy. I guess reiterating what Stacy said earlier, anything we can do to promote the migration to IPv6 and make it easier for people and less painful I think is a good thing.

The thing about the 50 customers, I think that should probably be smaller. Again, you know, anything to remove restrictions would be good. But I don’t see that as a big deal. I’ll leave that to others to argue that point.

John Curran: Okay. Far right microphone.

Gary Giesen: Gary Giesen, Advanced Knowledge Networks. I support this policy as written. I don’t think it’s perfect. I agree the number 50 should be lower, but I’m a pragmatic guy, so I’ll take what I can get.

John Curran: Okay. Center rear mic.

Jason Schiller: Jason Schiller, Verizon, UUNET. I’m a little bit confused by the discussion here. Do I understand correctly that the policy as written allows an end site which is not an ISP to get space and then use it for their own organization?

David Farmer: That was not my intent. Staff is suggesting that there might be some unclarity in that, and maybe we can deal with that in some minor edits, is what I would suggest. That’s not the intent of the proposal.

John Curran: The intent of the proposal is not to provide an end user with space. However, there could be an ambiguity in this proposal, and the staff comments have noted that an organization that says it’s a service provider, okay, even if its customers are internal – imagine a hospital multi-tenant, multi-site or university system – might easily meet the criteria of a service provider in this proposal.

David Farmer: I think personally the ambiguity exists in the current policy as it stands. So in one way it doesn’t make it any worse and I’m happy to clarify.

Jason Schiller: Removing that ambiguity, as written, I am opposed to this policy.

John Curran: If the ambiguity were cleared up?

Jason Schiller: I have some other concerns. There is no time bounding on the IPv6-based network connectivity services that are not necessarily Internet connected. And I think 50 is a low number, but I’m not sure if that’s low enough for me to be vehemently opposed to it or just moderately opposed or –

John Curran: Okay.

Jason Schiller: Or if I would accept it.

John Curran: Okay. I’m closing the mics. Last chance to approach the microphones. Far right.

Michael Richardson: Michael Richardson, Sandelman Software. Maybe I don’t understand. I thought it was if you were a known ISP and you had at least, in this case, 50 IPv4 customers, that you could have an allocation essentially regardless of whether or not those customers adopted v6. It was only if you were a new ISP that you had to have the plan to deploy to 50 customers. Do I misunderstand?

David Farmer: I don’t think you misunderstand it. That’s my intent, is that if you have v4, no matter how many customers you have, you can get a v6 assignment. If you’re multi-homed, no matter how many customers you have, you can get a v6 assignment. If you’re neither of the above, you need a plan for 50 customers over five years.

Michael Richardson: There’s a number of speakers that said they were concerned that the number was too low – was too high because they couldn’t convince 50 customers to adopt v6 soon. But they already had 50 customers, so presume they’re providing them with v4 at this point.

David Farmer: I think that was more a perception of things than an actual barrier. But that’s just my interpretation of it.

Michael Richardson: So that’s why I think the number is kind of irrelevant. It’s only for new, new, new, not known ISPs. And if we’re clear on that, then I support – I support the policy as written.

John Curran: Okay. Thank you. Microphones are closed, but I see people standing up. So, Kevin, would you like to directly respond to that?

Kevin Oberman: I just wanted to clarify that my remarks were couched in the idea of a new provider. I’ve already got IPv6 space. I’m just worried that a new provider is going to have – might have a hard time starting up today and saying we need IPv6 space.

John Curran: Are you also responding to that comment?

Joe Maimon: I was going to talk about the plan requirements.

John Curran: I actually ask that you be seated since we closed the mics for discussion. Sorry about that.

Cathy, last comment.

Cathy Aronson: I just have another question for the audience. This is Cathy Aronson. And if you have an answer you can approach any of us on the AC and let us know your feedback. But we actually tried to completely remove the 50-site requirement and then everyone was outraged because we might remove the requirement.

So we lowered it from 200 to 50 thinking, well, maybe that was a nice compromise. But if you have some idea of what you think might be something we could get consensus around that would be lovely. Thanks.

John Curran: Actually, we have a remote participant for the last comment.

Stacy Hughes: Remote participant, Lea Roberts, Stanford University. She supports the policy as written. She also believes replacing 50 with zero would be acceptable. One more: I think allowing sufficiently larger enterprises to qualify is a good feature.

John Curran: Okay. All right. Thank you, David.

[Applause]

Okay. The only thing between us and the lunch is a show of hands. Okay. On the matter of Draft Policy 2010-4: Rework of the IPv6 Allocation Criteria, I am going to ask for a show of hands. I’m going to ask for everyone in favor of advancing the proposal and then everyone opposed.

I see my machine is ready. Okay. On the matter of Draft Policy 2010-4: Rework of the IPv6 Allocation Criteria, all those in favor of advancing it, raise your hand now. Nice and high. We count hands, not feet. Raise your hand. Thank you. Okay. Thank you.

All those opposed on the matter of Draft Policy 2010-4 raise your hand now. Opposed. Raise your hand high or put it down. Okay. Okay. Thank you. They’re tabulating now.

I have no announcements other than lunch is served. It’s served in another room. It’s not served in this room. So you don’t need to come back in here with your plates and silverware. Do take your electronic possessions, though, because the room is not locked, I don’t think. Are we locked? No. Take your possessions. And we’re going to resume promptly at 1:30 where we have another policy proposal.

Here it comes. On the matter of Draft Policy 2010-4: Rework of the IPv6 Allocation Criteria, number of people in the room and remote, 138. Number in favor, 40; number against, six. This will be provided to the AC for their consideration. Thank you.

Lunch is served.

[Lunch recess 12:09]

Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests

John Curran: So I’ll do the introduction. Origin is Proposal 97 in June 2009. Draft Policy, 21st of January 2010. The current version is the March version of the text. You have it in your meeting packets. Shepherds are Scott Leibrand and Dan Alexander.

Summary: Provides rules for an expected queue of IPv4 requests when address space becomes limited. Requests need to be filled with ARIN’s available space, or request has the option of being placed on the waiting list.

Allocations and assignments are limited to one every three months. Draft policy is unique to ARIN. No other RIRs have taken up anything similar to my knowledge.

Legal liability: No significant legal comments. Any system to order and prioritize requests for resources which may exceed available resources must permit consistent administration.

Staff concerns: The text “but ARIN, at its sole discretion, may waive this requirement” gives no concrete criteria for staff to use in assessment of the request. This exception clause is open to interpretation since there are no guidelines or rules for staff to follow. It essentially allows ARIN to determine the policy criteria for who can or can’t qualify under this waiver.

That you’ll find in your text. It is a concern that we probably want to have addressed before implementation. If the community chose not to, we of course would do – muddle through as we usually do.

Resource impact: Development of software to monitor IPv4 returns. A waiting list that includes request size as well as minimum size acceptable. All require some development effort. There’s a little bit of impact here. It’s not onerous, but it would take a while to do the implementation of this policy.

PPML discussion: 40 posts by nine people. Three in favor; one against. Someone noted the policy lets the request just sit in the queue for the right block to become available. We don’t need a new policy that’s common sense. We don’t need to waste anyone’s time on PPML arguing over the last table scraps.

Suggestion to use PPML to evaluate an unforeseen change in circumstance: I wasn’t quite sure what that was either. And lots of discussion on the recovery of unused address space: would it occur, under what circumstances. I will note that we do recover address space on occasion. We recover, we reclaim, and we have returns.

So it is not without merit to have a policy that lets us address this. That summarizes the staff introduction. I’ll now have the AC come up, and this will be Scott Leibrand, to give the AC presentation.

Scott Leibrand: Really, this will be the last time you’ll see me up here, I promise. Okay. Why in the world are we up here? Once the free pool is gone, ARIN is going to be unable to meet requests. What then? We don’t know. Do we just give them to whoever happened to send in the request three nanoseconds after it came out? There’s all kinds of possibilities, but it’s totally unclear.

So what does this policy proposal do? It sets up a waiting list. It’s pretty common practice when you have a bunch of people waiting for something you get in line. Attempts to prevent requesters from gaming the system by submitting repeated requests. Basically it says that’s not allowed: avoids excessive address space fragmentation.

The idea here is if ARIN has a bunch of swamp 24s and you need a /16, do you get a whole bunch of 24s to meet your 16, or do you get a single block, the biggest ARIN has, and get placed on a list for more, go to the transfer process for more?

The proposal is fairly simple. It sets up a waiting list. Repeated requests are not allowed. If you can’t immediately get addresses, you’re welcome to go get them from transfer.

When addresses come in to ARIN, they go down the list. Find the first person on the list who’s got a block size small enough to be met by what they’ve got. Give it to them. Not a whole lot to it.

So this is the rationale from your packet. So I won’t read it. First-come, first-served basis. Waiting longest gets met first. If you get your address space via transfer, then you get taken off the waiting list. There were some questions that are answered. Again, these are ones that you can read. They’ve been answered on PPML. These are not tremendously new.

So I’m not sure what issues, questions people have. I know I’ve gotten several questions about the mechanics of this. So I expect a few of those. I don’t know if there’s questions or comments about the necessity for this. If the way we’re doing it makes sense or what. Aaron or John?

Aaron Hughes: Aaron Hughes, 6connect. I would like to have an understanding of what would happen today if there were no policy change and we would run out of all resources and hypothetically ARIN would reclaim, say, a /8. What under today’s policy would happen?

John Curran: So there’s no explicit waiting list concept right now. So we haven’t specified what happens when we finally get to wanting to assign your resources. There is a transfer list, a transfer listing service that will soon be open to community consultation momentarily, and you would be available – you’d be able to be on that transfer listing service.

The problem isn’t if one party was on that listing service and ARIN got a resource block that would serve them, we’d probably figure out how to put 1-to-1 and make success. The problem is if there’s 30 or 40 entities waiting for resources and resources come back, do you serve the order in which they came in? Do you serve the maximum number which would be the smallest number of – the smallest request possible to maximize the number of requests utilized.

So right now what would happen is if everyone was on the transfer list, they’ve already been told you qualify. You’ve already been told we don’t have resources. The resources come back to ARIN. We have no policy that says how to select them.

I probably would pull them in first-come, first-served in the same order of application. But first-come, first-served may not be what you want, particularly if that first request is for a /10 and it depletes whatever comes back rapidly.

Does that make any sense?

Aaron Hughes: Yeah. So far in the proposal, I would support something like this as long as it had a limit for the queue, for example, a /8, and once you have a total of some arbitrary number stop taking people in the queue so it doesn’t require any more staff effort. Seems like it’s worth a reasonable amount of effort and a reasonable cost.

But I can’t see spending resources building a giant queue and send replies back to people who are never going to get resources.

John Curran: Got it. So as written, because of the cost, you’d be against it. But you think it could be modified?

Aaron Hughes: I could really go either way, actually. So something is better than nothing. I don’t believe I’ve seen anything else proposed. So something, if there’s nothing today and you don’t know what to do, some direction is better than no direction. So as written, I support it, but also it would be nice to have a limit.

John Curran: Got it. Far left side.

Tiberiu Ungureanu: Tiberiu Ungureanu, Ecommerce. As written I don’t support the policy because of the waiting queue. You either need IP space now or you can do without them for a while. And if you need IP space now and ARIN does not have enough space to accommodate your full request, you should be happy because you can get something. So you should modify your request to get whatever you can get.

And the Internet is a business – Internet business is something that moves very, very fast. If I cannot get IP addresses now, I will figure out something. I will migrate to IPv6 or I will change my business model.

Putting stuff in a waiting queue doesn’t make much sense to me. I either need IP addresses and I get them now and I get whatever I need, or if I can wait then I don’t really need them. So the request should be denied.

John Curran: Okay. Thank you. Far right.

Michael Richardson: Michael Richardson, Sandelman Software Works. I have a question. Is the content of the queue public?

Scott Leibrand: As it stands now, there is no requirement to ARIN to make the waiting list public. However, as John mentioned, the contents of this list may very closely approximate the transfer listing service in that someone who wants address space probably wants to get it from ARIN if they can get it for free, but they probably want to be out there to get it via transfer if they can get it for cheap.

If I remember correctly, the suggestion to staff – and they’re going to be doing consultation, so this will be up for discussion – was to allow people to publicly list themselves on the transfer listing service but not require it.

So I would say that this particular waiting list itself would not be public. You could get an idea of the people that are on this list by the people who are on the transfer listing service.

Michael Richardson: Would, therefore, the total need or the distribution of need be public?

Scott Leibrand: I would anticipate that ARIN staff will do a good job of making summary statistics available like they always do.

John Curran: Do you support the policy proposal as written?

Michael Richardson: I – I think that – I think that it has value. I – I think that the question of whether the queue is public or not and how much information is there is of great concern, and I don’t know whether it’s better to be public or not public.

I believe that there’s gaming that could happen of requests, as the previous gentleman said. You go and figure out what might become available and ask for that.

So I don’t know what the game is because I haven’t thought about it. But it’s clearly different games for different pieces of information. So I think actually we need to figure that out. And I think I trust the AC to figure that out and add it. So I would support it as written that way.

Scott Leibrand: Don’t just trust us, help us with the policy proposal to do what you think is the right thing with the publication.

Michael Richardson: I don’t know what the answer is. But I suspect the answer may be to – it may be that you need to – if the information is derivable, then you might as well give it to everyone. I think that may be the answer.

John Curran: The default behavior would be that – when we see policy proposals we would not normally make information available about requests, because by definition that’s usually coming in over an NDA. While there would be a transfer listing service where people could say I have a need, do you have a block, that would be voluntary for someone to put themselves on if they so desire.

So for purpose of interpreting this, this list, per se, is almost certainly going to be private. There’s nothing that says ARIN would be disclosing. And in the absence of that, we have to treat everyone’s requests as confidential, so just for your consideration purposes.

Okay. Center front.

Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. I support the proposal as written. I think that it’s a good step towards what we’re going to need for a waiting list. I don’t think the waiting list should be public. I think that publishing the waiting list actually probably enables more games than it prevents in this particular case.

And I think that the fact that everybody on this list has the option of publishing their request if they want on a listing service covers the best of both worlds as best we can.

I hope that nobody is looking at this listing – at this waiting list as being we can get v4, we just have to wait a little longer. I hope people are recognizing that v6 is the way forward; that you’re not going to be able to keep expanding in v4 forever.

More layers of NAT are not going to help. Waiting lists are not going to help. The transfer market, if it is unsuccessful, will not help, and if it is wildly successful, will destroy the routing table. And thus end v4 rapidly, much more rapidly than anybody is hoping.

So I think that this is as good a policy as any of the other v4 end game policies, and we might as well add it to the list of end game tools that people can bandy about.

But the wall is a wall and we’re going to hit it.

John Curran: You support it, but you don’t think it will be particularly effective and maybe we should warn people of that accordingly?

Owen DeLong: Absolutely.

John Curran: Like joining the waiting list to return to the gold standard. I got it. Far left side.

Dave Barger: Dave Barger, AT&T. I do not support this as written. Couple of thoughts about the waiting list: I think that can give a perception in the community at large that, you know, if I wait around I can still get v4 addresses so maybe I can postpone v6 a little bit, because maybe a little bit of a false sense of security.

A couple of other things with the wording: it says under 4.1.8 that ARIN will provide the requesting organization with the option to either modify the request and request a smaller size block.

I would like a little clarification on what is meant by a smaller size block. For example, if you go in and ask for a /13 and ARIN says we don’t have a contiguous block, then will the rule be that you will immediately be considered for a /14, or – I mean, how is that going to work. I think that needs some clarification.

Scott Leibrand: Right. So the way this is meant to work, if you come asking for a 13 and all ARIN has is a 16, they will tell you: We don’t have a 13. We have a 16. Do you want it or do you want to go on the waiting list for a 13? And that’s your choice.

Dave Barger: Okay. So that dialogue would happen. It’s not spelled out in here, but that’s the way it’s supposed to work; that there’s that full disclosure, we have a 16, you can have it now or you can wait.

Scott Leibrand: Right.

Dave Barger: Okay. I think that was the end of my question. Thanks.

John Curran: Rear microphone.

Milton Mueller: Milton Mueller, Syracuse University. I have a question somewhat related to the last one. It’s a question about how this works. So suppose on a particular day you get four requests for a block of size – the first one is three times X and then the next three are X. So if the person who was requesting three times X is first in line and a XXX-size block is liberated somehow, then that person gets it. Right? All of it, and then the other X waiters just wait.

Now, suppose at the end of three months you’ve got a two times X and you think if you wait another week you might get that third X. Well, what happens, you just have a cut-off date?

Scott Leibrand: Third contiguous X or a third X from somewhere else?

Milton Mueller: Well, that’s another question, right.

Scott Leibrand: The way it’s structured right now is we don’t wait around for contiguous stuff to open up because the expectation is anything contiguous is going to come back at once or not at all. If there’s a XX block that comes back and there’s a XXX and an X and an X and an X on the waiting list, XXX doesn’t get anything, the next two Xs in line behind him get it; XXX stays in the waiting list for a XXX-size block to come around.

So you’re going to have a waiting list that has people with big block requests sitting at the top of the waiting list. So they don’t get it the first time around because the thing available wasn’t big enough, but when something big enough does become available, then they are serviced.

And one important part of this is we do not allow someone who wants XXX to get XX plus X, if those are discontiguous. They have to be a contiguous block.

Milton Mueller: Thank you for answering that. Few other comments, then, in terms of this encouraging people to not convert to v6. I think that’s kind of a bogus argument, because it’s my impression that running dual stack will also require v4 addresses and it might require people to make additional requests. And I happen to believe that we’re going to be running dual stack for a decade or two. So I think you want to allow people to do that.

And then I think that the – I don’t understand why you would make the transfer market list public and not this list. I see no reason not to do both or –

Scott Leibrand: Simply put, publicly providing this list did not seem to be of any benefit to me, so I did not provide any guidance to staff on that. Their default position is not public, but there’s this other thing, this transfer listing service that we’ve said we want to be optionally public. So it kind of serves the same purpose.

So it’s not really the – we don’t think this is good to have public. We could theoretically have this optionally public, too, but then you have two optionally public lists and that’s kind of weird. I think full public has some problems that we could address.

Milton Mueller: I’m saying, to me both of these are depleted free pool rationing mechanisms, and they’re in the same status. One of them is using more or less the price system. The other is using a queuing system, and publish them both.

John Curran: A party could ask ARIN, we need resources, qualified for a block. And then when they qualify for a block, they say, oh, you don’t have it now. When you have it, if you have it, I’d like to receive it and be put on the waiting list but not want to disclose any information at all that would allow parties to contact them and say, hey, I got addresses. Okay? You might not want to be contacted.

So by definition we wouldn’t do that. If you want to be contacted, because you have a documented need and you can fulfill a transfer, then you have a list to be put on. And you will be – I’m sure you will be contacted. There will be parties with addresses and they will want to consummate a transaction.

And so we didn’t want to force the two because there is an issue of how often do you want to be contacted to say you’re needing addresses.

Milton Mueller: Okay. I see the distinction. Thanks.

John Curran: Front and center.

David Farmer: David Farmer, University of Minnesota, ARIN AC. I support this policy as written. We need to do something, otherwise ARIN staff will end up be stuck figuring it out for themselves. I think it’s best for us to give them guidance on what we as a community would like. Honestly, I think this is close enough. I don’t think we need to spend a whole lot of effort on it. A few tweaks would be fine. But I’d really like to see this get through and not have to take another policy cycle.

John Curran: Okay. Front center.

Wesley George: Wes George with Sprint. I do support this policy. I think the main comments I wanted to bring up was a response to a previous commenter who had said this is a fairly binary exercise, you either need addresses and you need them now or you don’t need them and therefore you shouldn’t make the request. I don’t think it’s nearly that black and white. The reality of the way IPv4 allocations are done today, it’s a percentage utilization.

And I can go above that threshold without running completely out of addresses for some period of time, depending on how much address space I have to start with, what my run rate is, all those things.

I know personally my company has a relatively linear usage of addresses. We can see it coming. We know when we’re going to have to make our next request for allocations, and it’s, if we go on a waiting list, it just means that we chew into our margin.

The other thing is that the – you know, the comments that kind of go to the effect of this is rearranging deck chairs on the Titanic, why don’t we just let people fail, I kind of am of the mind if you’re still looking at this as a way to keep your head in the sand a lot longer, I totally agree with that sentiment, that it stops being my problem, right?

But what this really is is the ability for those of us who are trying to plan ahead but the business reality or the technical reality, whatever it is, makes it impossible for us to just flip the light switch and go to IPv6 and stop using IPv4. This gives us a little more of a softer landing.

John Curran: Okay. Center front.

Jason Schiller: Jason Schiller, Verizon, UUNET. I have a lot I want to say about this, but first I want to clarify something. There’s a sentence in here about not gaming the system, and I’m trying to understand if what I’m about to describe is considered an abuse of this policy or is using the policy as intended.

I have justified need for a /8. I submit my paperwork. Everyone rubber-stamps it, yes, you do have justified need for a /8. I find out that there’s no /8s available but there’s a /16 available.

So I say you know what, probably not going to be a /8 available. I’ll at least take the 16. Can I then wait three months and use the same justification to get back in line if there’s a line at that point? And ask you again for my /8 and find out again that the /8 is not available but now there’s a /20 available and say, you know what, I will take it. And do this every three months.

Scott Leibrand: Yes, you may do that or you may go to the transfer market.

Jason Schiller: That would not be an abuse of this policy?

John Curran: As long as you wait three months, that’s fine.

Jason Schiller: Thank you.

Scott Leibrand: I suspect we’ll go from 16 to 24 rather quickly. Probably in less than three months.

John Curran: Jason?

[Laughter]

Having been informed of your question –

Jason Schiller: I think I like the policy a lot better now. So I have to think about it a little bit more, but I think I’m in favor.

John Curran: You’re in favor, now that you’ve been able to clarify that that behavior wouldn’t be gaming?

Jason Schiller. Right.

John Curran: That’s reassuring, I guess. Thank you.

[Laughter]

Remote comment.

Tom Zeller: Randy Carpenter, First Network Group. I don’t think the list could be public. It would encourage gaming the system by gauging the current requests and who they are and who they are for. Maybe an option to publicize, certainly not the default. And I do support the policy as written. Thank you.

John Curran: Microphones are open for comments on this. I’m going to be closing the microphones soon. If you wish to comment, find a microphone. Center front.

Matt Pounsett: Matt Pounsett, Afilias. A couple of comments, I guess. On the question of whether there should be a public list, I’d agree with that last comment. I don’t think it’s a good idea. I don’t see any point behind it; that if somebody wants to be listed for some reason, they’ll go to the transfer or they’ll go to the transfer market and get listed there.

And today we don’t – ARIN doesn’t publicly announce every request that comes in. You know, it doesn’t become public information until after it’s fulfilled. So I don’t know why we change that.

Scott Leibrand: Even then, you have to go looking for it; they won’t tell you about it if you ask.

Matt Pounsett: Exactly. The other comment I had was related to the question of what happens if something is returned that is – that doesn’t quite meet the request of the first person in line.

The mechanism you described, the sort of best-fit thing, is how I think it should work. But from reading this, it wasn’t clear to me that that’s how it works.

When I read this, it seems like you wait until enough comes in to fill the request of that first person in line. So I support the proposal, but I’d be happier if something was tweaked just to make that clearer.

Scott Leibrand: Which behavior do you want? I’m not clear. You confused me.

Matt Pounsett: I was talking about the situation that was asked about a few questions ago, what happens if there’s a person waiting for a –

Scott Leibrand: I understand that. Which behavior do you prefer?

Matt Pounsett: I prefer the behavior he described, which is that if someone’s waiting for a /8 and there are a bunch of people behind them waiting for some /16s or whatever.

Scott Leibrand: 16 comes in.

Matt Pounsett: 16 comes in, it goes to one of the people with 16s. Well, although I suppose unless that first person in line changes the request –

John Curran: We need to return this to a question and dialogue sort of mode. So as written…

Matt Pounsett: As written I support it. But I think the wording could be clearer on exactly what happens when something is returned that doesn’t quite meet the needs of the first person in line.

John Curran: Okay. Got it. Do you want to clarify how it works?

Scott Leibrand: Yes. ARIN will make each allocation and assignment as a single contiguous range of addresses. That eliminates the possibility of ARIN collecting a bunch of /10s that are discontiguous and giving them out to a guy who wants a /8.

Pretty much the only thing that’s left is the question of whether, as a block comes in, everybody at the top of the line gets to choose whether or not to make their request smaller at that point.

As it’s written, you only get to make your request smaller when you first make the request and there’s something in the pool. After that, you’ve got a certain size. You’re in the list for that size. If you want to change that, you go to the back of the line.

John Curran: Right. That’s the part I was going to correct with Jason, is, to be clear, you said, well, I asked for an 8 and it’s not available, but a 16’s available, I’ll take the 16. The problem is you have no visibility into what’s available at all. And because you have no visibility in what’s available, you get – said 8’s not available. You can be put on for an 8 or 12 or 14 or 16 or 22. We’ll put you on for whatever you want. But you don’t have visibility as to what is in – what is currently available or in the queue.

Scott Leibrand: Do we think that’s an issue? Do we think the queue size, the what’s left in the free pool should be publicly visible? Because we might want to tweak this to allow that or it might be a suggestion process thing to just go ahead and publish what’s left in there in free pool.

John Curran: So there’s a race condition here. Imagine when you come in asking for your 8, there are people waiting for 10, 12, 13, 14 and 15. And there’s currently a 16 available. Okay.

There’s no way to notify everyone fairly, hey, there’s a 16, who gets it. Okay? If you’re in the – as written, if you’re in the list and you’re the 10 to 12, the 14 or the 15, you’re in the list. When Jason comes in for the 8, if he says I want to be listed for anything 8 through 15, he’s in the queue. If he says 16 and there’s a 16 out there waiting, the moment you put your request in, you’ll get the 16 because everyone else is waiting for larger blocks.

Jason Schiller: Oh.

Scott Leibrand: Because they chose to not go for the 16.

Jason Schiller: So if I come in with – if I come in with a request.

John Curran: Get in line. Matt’s in line. Ask your question.

Matt Pounsett: Just to clarify, what you described there is what I understood to be the case from what you described earlier. What my comment was is that from just from reading the text, that wouldn’t be clear to me.

John Curran: Got it.

Matt Pounsett: And so I think – I don’t want to try and wordsmith it here, but I think something needs to be tweaked so that reading the text it’s clearer that that’s what’s going on.

Scott Leibrand: If you have policy suggestions, follow up with me. Otherwise, I expect staff will put together a how-to “this is what it looks like” guide at some point, and that’s an implementation detail.

John Curran: We’ve got Marla at the end.

Marla Azinger: First I want to start with a question. Well, it’s a scenario. If ARIN only has one /16 in its queue and it has two customers come to it that both want a /17, what do they do?

John Curran: We break it up and allocate.

Marla Azinger: So that sounds like you’re breaking up contiguous address space to me.

Scott Leibrand: What do we do today.

Marla Azinger: So my point is there’s an option missing from this, which is not manage it like that. Give people also the third option to say if I come to you for a – /8 seems to be the popular thing, but that’s really not what it would be. But if I came to you for a /8 and you had here, here, here, and that’s all you had, then I’d say, okay, give me what you have.

Scott Leibrand: I explicitly wrote this to prevent that because I think that will explode the routing table.

Marla Azinger: Right. Here’s my point where that doesn’t matter because if ARIN is going to go ahead and split up a – if they’re going to split up a 16 to accommodate two people that want 17s, you just now created two announcements when I would have only made one.

Scott Leibrand: So in the situation as it is today, when someone comes in and requests a 17 or whatever, we break up a free pool and give them a 17. There are as many routes as there are requests. And under my situation, there are as many routes as there are requests.

In the situation where the someone with the /8 gets to vacuum up all the 16s, at that point you’re still no worse. But then you have all these unmet requests that then have to be met with smaller blocks or some other, those people will be pressuring someone else to deaggregate their big block. So it’s not the first-order effect that causes this deaggregation, it’s the second-order effect of the unmet requests forcing more deaggregation.

John Curran: Marla, as written it was designed to prevent the aggregation of blocks to give it to the person who wants the 8 and give them all the pieces that are available.

My question is, I know it creates more routing, but as written would you support it?

Marla Azinger: No. And I was actually – he can speak. He just walked in the door. He doesn’t either.

John Curran: As written you don’t support it?

Marla Azinger: I do not. I believe we need to do something, don’t get me wrong.

John Curran: But this isn’t it?

Marla Azinger: Yeah, this is not it.

Jason Weil: Jason Weil, Cox Communications. So this doesn’t update 8.3 at all, does it?

John Curran: No.

Jason Weil: So using that example of a /8, if you’re requesting a /8, get approved for a /8, there’s no /16, but there’s a /9 available on the transfer market, but you can’t qualify for it because it’s not an exact match, then you have to take the 16 and go back?

John Curran: So as presently written our transfer policy is an exact match, okay, and does not interface with this in any way, you’re correct.

Given that restriction, are you in favor of the policy as written?

Jason Weil: I’m leaning in favor of it.

John Curran: I’m leaning in favor. Thank you.

Far right microphone.

Michael Richardson: Michael Richardson, Sandelman Software Works. So based on what Michael said, pointed out that if you can see the queue, then you know all the requests that are not available. So you may not be able to see what’s available, right, but you can see what’s not available; so you shouldn’t ask for that, right?

John Curran: You cannot see the queue as this proposal is written.

Michael Richardson: I want to emphasize, if you could see the queue then you would know what’s missing from the availability pool.

Scott Leibrand: This will be all of four days that this happens, I think.

Michael Richardson: No, because, see, people could be waiting for a long time. Someone may have returned a /18 and no one’s asked for a /18. There’s no one visible in the queue.

If you saw someone go into the queue and disappear again, you would know there were /8 – asked for an 18, you know there were /18s available or whatever. You could see what was available.

So it tells me that – and several people said that – obviously, I agree – seeing the queue lets you game the system, but also seeing the free pool lets you game the system.

John Curran: Correct.

Michael Richardson: Correct? So I agree that the queue should not be visible, and I may even say that the free pool should not be visible.

John Curran: Neither are presently visible as this is written. Given those two constraints, would you support the policy?

Michael Richardson: Yeah. In fact, I think I understand now that it’s critical to the policy that those two constraints be like that.

John Curran: Thank you. I have – okay. Kevin, you’ve moved with respect to the two people behind you.

Kevin Oberman: They pointed out that I hadn’t spoken on this one yet and they had.

John Curran: Okay. But I also have – in which case hold. I have R.S., who hasn’t spoken.

Rob Seastrom: I wanted to get clarification on Marla’s concern. Marla, you said you were worried that somebody would request that there would be two people requesting /17s and the 16 would come in and ARIN would break it up into two 17s and create extra slots in the routing table? That’s correct?

Marla Azinger: Right. Because they’re saying I’m not allowed to cobble together address space in order to fulfill my one big request; yet, if you look the other direction, all of a sudden you’re splitting it up to help two other entities.

Which, no matter what we do, it’s not going to be fair for somebody. I am, I know, in the minority here because I have a medium-sized network. I’m Tier 2. So my request would be one of those bigger ones that I get denied, in this case, if we follow this and say keep coming back every three months or something instead of letting me say, okay, give me what you’ve got and then I’ll leave you alone for a while.

Rob Seastrom: I understand, but what I’m trying to do is reconcile that with understanding how that’s different from the current status quo, where ARIN has issued /8s from IANA and does not hold on to them exclusively for people like Mr. Schiller behind you who might actually be able to justify a /8 and instead breaks them up into /18s for all of us little people, thousands of them.

Marla Azinger: You keep saying current. This isn’t current. This proposal – I’m just trying to say stick to what you’re saying. If you’re going to say we’re going to keep this and we’re not going to split it up, if you have a 17 and two people come to you wanting 18s, then say no. Whoever wants the 17, give them the 17 but say no to the two that want the 18, because you’re essentially doing that to me by coming – for when I come to you and say, hey, give me what you’ve got.

So I’m saying if you want to go with one theory, stick with it across the board and don’t be, in special circumstances, saying, okay, well, in this case we’ll split it up.

John Curran: But the reason you’re arguing that is because of the routing implication of splitting it up.

Marla Azinger: One of the reasons this was done was not just the fairness, but part of the mind thought was, oh, well, it will help reduce routing, which isn’t true.

John Curran: Okay. But the routing – I think what R.S. is trying to say is the routing impact of splitting up a block to serve the two 17s is no worse than as it is right now today when we split up a block.

Rob Seastrom: That’s correct.

Marla Azinger: We agree on that. My point is stick with one theory.

John Curran: Got it. And you’re still against the policy proposal?

Marla Azinger: I am, because I need to cobble.

John Curran: Right. R.S., given that, are you in favor or opposed to the policy?

Rob Seastrom: I am leaning in favor of this policy.

Kevin Oberman: Kevin Oberman, ESnet. I see what looks to me like a grossly unfair race condition appearing in this down the road. Maybe I’m missing something. Jason’s /8 request comes in. Before that, Marla’s network goes out and says I need a /10. There’s no /10s available. The biggest thing that’s available is a /18. Marla says I’m sorry, an 18 is just not going to do me any good; I’ll have to wait.

John Curran: Just for point. She would not know an 18 is available. She would be told a 10 isn’t.

Kevin Oberman: She would know that.

John Curran: She could say I’ll wait for a 14 or – if you have it. Or a 15. Or an 18.

Kevin Oberman: Okay. I thought you said that when Jason came in and asked for his 8 he would be told that he could do it with 16.

John Curran: I specifically told Jason he would not know that a 16 was available.

Kevin Oberman: He wouldn’t know when it came in. But if an 8 isn’t available, would he be told you can have a 16 –

John Curran: 8s available, he’d be satisfied with the request. If his request was for an 8 and an 8 wasn’t available, he’d be told you’ll be listed for an 8 or something smaller that you designate.

Kevin Oberman: Ah. Okay. That obliterates my issue.

John Curran: That’s what I’m trying to say, Jason. You may request a smaller size and be put on the queue with that if you want.

Jason Schiller: But I have to pick the size?

John Curran: Right.

Scott Leibrand: You can’t have it all, Jason.

John Curran: Jason, are you in queue? Or are you in fugue or…

Jason Schiller: I’m in queue.

Unidentified Speaker? Waiting for a /8.

John Curran: You might be there a while.

[Laughter]

Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. Somebody mentioned disclosing the contents of the free pool or the details of the free pool and a few other things that they thought it would be good to disclose. I think that this is one of those situations where publishing less information will contribute to less gaming of the system.

I think it would be very, very bad to disclose details about the free pool and the size of blocks that are available and whatnot.

And I think that if we are going to have this waiting list, the waiting list needs to be blind. It needs to be as John has described it, and anything else will invite optimization techniques that will be in the end unfair, I think.

I also want to respond to Marla’s statements. I think that what we’ve proposed as is is quite a bit more fair than the alternatives. I think this does stick to one theory. I think that refusing to break up a block is – in the end game, is just not a viable policy, and I think that allowing somebody who has a large request to get a whole lot of the small breadcrumbs to try and make a big request is nothing more effective than a way to watch the breadcrumbs get sucked up as rapidly as possible. And I don’t think that helps either.

John Curran: Okay. Wait. Come on back. Whoa. Whoa. Come on back, Owen. As written…

Owen DeLong: I still support the policy as written.

John Curran: I’m closing the microphones. If you wish to speak about this, approach the queue. Remote participants, I’m closing the queue. Same thing. If you wish to speak, type your comments now. Far left mic.

Chris Grundemann: Chris Grundemann. This is probably getting a little tedious, but to be absolutely certain of what would happen here. So if I come to ARIN and ask for a /8, you say no, then I can say, okay, /7 –

John Curran: No.

Chris Grundemann: – and you say no.

John Curran: Oh. So, first, /7 is bigger, so you’re going the wrong way. If you say /8, ARIN says no, would you like to be listed for a /8 or something of smaller block, longer prefix, 9, 10, 11, which means we’re going to put you on the list for that for when it becomes available.

Chris Grundemann: It’s a two-strike system, right? If I come in and I guess wrong twice –

John Curran: Yeah, if you said your smaller block was /24, we might just give it to you, if that was available.

Chris Grundemann: But you get two chances, basically, is what it comes down to. You come in with your request that you can justify, and if you get told no, you get to pick one to go on the list with. If that one happens to be available, you get it. If not, you sit on the list.

John Curran: Right. Right. Theoretically, in a world of very empty queues, because there’s only the combinations really practically of /8 through /32, I guess, 16 people in the universe could exercise effectively a second chance and be satisfied on the spot, because they could guess today’s winning lottery number is /19 and get their block immediately.

Given the number of requests that ARIN handles, those queues will all be occupied by hundreds of entries after the second week. And so it’s a two-strike method where you’re being put on a queue.

Chris Grundemann: Thank you.

John Curran: But, yes, you’re correct. Back to the microphone. Thank you. Given that, would you support it as written?

Chris Grundemann: Yeah, I think so. I think I’ll support it.

John Curran: Thank you. Closing the microphones. Five, four, three – microphones are closed. Center front, Jason.

Jason Schiller: Jason Schiller, Verizon, UUNET. A lot of people have been talking about what information should be published in terms of what’s in the available free pool and whether that’s unfair because people will try to game the system. And now that I understand the nature of the lottery, I understand the gaming of the system comment.

What I wanted to talk about was when I decide to get in the queue, I guess this doesn’t apply now, because I was assuming that you would offer me the next largest available block.

So when I go out to a restaurant and they say we can’t seat you immediately, it’s nice to know how many tables of what size are in line in front of you.

And that was the sort of – the generic information that I was hoping that you would publish when I would decide to take the smaller block or get in line. But I guess at this point there’s no choice to take the smaller block, so…

John Curran: Right.

Jason Schiller: So it doesn’t matter. So I’m opposed to this policy because I don’t think we should be giving out addresses through the lottery.

John Curran: You don’t think we should be giving out addresses through a lottery.

Jason Schiller: Right.

John Curran: Because if you would just go list for your size that you need, that would be fair, but because we offer you the choice, that constitutes a lottery?

Jason Schiller: Yes.

Scott Leibrand: Until two weeks go by and every slot is filled up.

John Curran: Right. Realistically it’s a lottery with 24 positions and a long queue for winners in every one?

Jason Schiller: Yes.

John Curran: Okay. But, given that, you’re against the policy?

Jason Schiller: Yeah. I think it would be better if either you offered the next largest block available and tell them to go away for three months, or whatever the time period you think it is, or if you said you are Nth number in line for this size address; thank you for asking for a /12, you’re the 14th person in line.

John Curran: So the question that comes up, the degenerate case, is when you offer that, people will every three months change their circumstances and attempt to hit the next queue. And I can see the –

Jason Schiller: But the existing queues now have three months of people in them.

John Curran: ARIN queue size board and people swapping this information around and little bars showing – this information will become generally known. I guess I’m wondering, would you prefer that ARIN published the queue length of all the available queues, since the moment we give it out to a party, we’re effectively going to result in it becoming common knowledge? Would that make – publishing the queue lengths, would that make it fair and make you support the policy?

Jason Schiller: I think so, yeah.

John Curran: But, as written, you don’t support it?

Jason Schiller: Correct.

John Curran: Remote participant.

Tom Zeller: Let’s see. Sorry. Randy Carpenter, First Network Group. I agree with Owen on the free pool. It should be kept hidden. Still support the policy. Smiley face.

John Curran: Center rear mic.

Milton Mueller: Yeah, I think – Milton Mueller, Syracuse University. Jason was getting at some of the issues that I’m going to raise. I think the fallacy that’s going on in some of the thinking here is that if you keep everybody in the dark that everybody is going to be nonoptimizing in their behavior and they’re just going to innocently put forward what they really need. This is clearly not true.

What they’re going to do is they’re going to optimize. And they’re going to optimize in ignorance. And so the most rational strategy – and I haven’t worked out the game theory here yet, but somebody should. You’re dealing with information and asymmetric information and all of that.

The most rational strategy is to request a smaller block than you actually need. And that gets to fragmentation, does it not?

John Curran: Sure.

Milton Mueller: So you’re encouraging people to say: I think I need a /10, but I don’t think there are any out there. So just to be safe I’m going to request maybe a /12 or something, choose your step.

And maybe you were right the first time. You could have gotten a /10 and you’re not going to tell them until they commit themselves, right?

John Curran: The way the policy’s written, they would get the answer that 10 is not available and would have the option of being listed for a /10 or a 12 or any – whatever number they want. So we tell them no on the 10. The real question is do they get listed then for 10 or less.

Milton Mueller: Exactly. So most people will take a step down after being on for what they get on there for – can they pull themselves off the list at any moment.

Scott Leibrand: Go to the end of the line.

Milton Mueller: Go to the end of the line. You really have to make a really good guess that first time and you’re increasing your probability by lowering, getting a smaller, more fragmented block.

Let me just say this: The gist of my comment is I still don’t understand – people say that everybody should be kept in the dark. What kind of gaming are they concerned about if you actually know what’s in the free pool. And of course the proper way to handle this is through an auction. Just waiting for the gasp there. I guess I didn’t hear that. You’re not going to do that, clearly.

So what are you accomplishing by keeping people in the dark about what’s in the free pool? What kind of games are you afraid of?

John Curran: So realistically, remember, we have a very high level of demand and a very small supply at this point. So if you display what blocks are available, that will create parties that will show up and immediately deplete those blocks. Because the number of parties seeking addresses will outnumber the availability in multiples of hundreds to one.

So if you show three here, two there, seven there, eight there, you’ll get requests that coincidentally match three here, seven there, two here and eight there, until all the blocks are gone and all the queues are empty.

Milton Mueller: You’re not doing needs assessment to find out how many of those are valid?

John Curran: Doesn’t matter. When you’re outnumbered a hundred to one, and when people know what block they have to justify, when you go into your request, you could shape your request potentially to hit a block by deciding, well, I’m only going to upgrade that part of the network in this request; I’ll come back with another day.

So the problem you have is if you display what’s actually available for blocks, you can do that. But that’s only relevant for a very brief transitory spike. And then there’s nothing available –

Milton Mueller: What you’re complaining about is that you’ll actually meet supply and demand very quickly.

John Curran: No, I’m not complaining about it. I’m saying it’s only operational for a short number of weeks, and then all the numbers read 0 for all the blocks, which is fine. But effectively it then comes back down to game theory, because the information is 000 and I’m not showing the queues, but you don’t know what’s going to come in in any case; you still have to get in line.

So telling them what blocks are available right now presumes there’s actually blocks. And that’s actually not a common case in this circumstance.

Very quickly everyone’s going to have to get in line and see what gets returned. The queues that might be popular are /24. Because if someone really does ever get off of v4, then that might get returned. Or fragments of /16, not necessarily the whole one because someone may want to keep some.

So you have to guess. And I’d be far more inclined to guess on what the shape of the potentially returned address space is than what ARIN’s actually holding.

So my answer to you is you can show people the queues. It doesn’t solve the problem for more than the first ten days, then they’re back to having no information because all the queues are empty.

Milton Mueller: You’re talking about the returned address space rather than the available address space, right?

Scott Leibrand: One other thing to keep in mind, Milton, is that you’ve got a single request that qualifies you both for the waiting list and for the transfer market. If anyone wants to get transferred space, they’ve got to put their request in for the amount of space they want to get transferred. If they go make a much smaller request for the waiting list, that’s all the space they can get transferred to.

So that kind of alleviates some of this I’m going to make a smaller request than I need, because if you want space, you’ve got to get it one way or the other.

John Curran: Queues are closed. We have one last comment from the table. Heather.

Heather Schiller: No, I was going to –

John Curran: That’s fine. So let’s thank our presenter. Thank you, Scott.

[Applause]

Okay. Now is the time we provide guidance to the AC. I see our tabulation engine spinning up, yes, yes and yes. I’m going to get them some hats that say ARIN Tabulation Engine. Probably long overdue.

Unidentified Speaker: Multiprocessor.

John Curran: It is a multiprocessor.

So the matter that is before us is Waiting List for Unmet IPv4 Requests, Draft Policy 2010-1. I’m going to ask for a show of hands in favor and show of hands against advancing this policy proposal. I want everybody to be ready.

Okay. So here we go. All those in favor of advancing Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests, raise your hand now. Nice and high. One hand. Nice and high. Some day I’ll get some machine/computer noise playing in the background, hear the tabulation engine. No?

Okay. Thank you. All those on the matter of Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests, all those opposed to advancing it, raise your hand now. Opposed. Nice and high. Thank you.

Okay. Numbers are coming forward. I thought they were coming forward. I’m on the waiting list for the numbers.

Okay. 2010-1: Waiting List for IPv4 – Unmet IPv4 Requests. Number of people in meeting room and remote, 120. In favor, 41; against, 16. This information will be provided to the Advisory Council for their consideration.

NRO NC Report

Jason Schiller: So this is the Number Resource Council report. Who are we? Well, we have three members in the NRO from the ARIN region: myself, Louis Lee, and Martin Hannigan.

And what is NRO? Well, the current members are the five RIRs and they come together and speak as a single voice as the Number Resource Organization. That’s divided up into two pieces: the executive council, which are the RIR presidents and speak on behalf of the RIRs, and the Number Council, which speak on behalf of the community.

My slides are gone. Sorry about that. Okay. Sorry about that.

What does the ASO AC do? Well – what do we do?

John Curran: What operating system is that?

Jason Schiller: It’s Windows.

We appoint seats 9 and 10 to the ICANN board. We appoint a representative to the ICANN nom com. We objectively process RIR-related global policy proposals that are submitted from participants. And we certify that those policies have followed the policy development process in each of the five RIRs and send that up to ICANN. From time to time we’re also consulted from ICANN for advice on these and other issues.

We also define our own operating procedures and how we process policies and how we act internally.

So what’s happening? Well, we’ve got some new people on the NRO NC. Alan Barrett was reelected from AFRINIC. Tomohiro Fujisaki was re-elected from APNIC. And we appointed Seat 10 to the ICANN board with Kuo-Wei Wu. We also selected Wilfried Woeber to be on the ICANN nom com for this year. And we have a meeting coming up in Brussels.

So we also processed global policies. We’ve got two of them right now. The first is 2009-6. That’s the policy where IANA is going to no longer differentiate between 2-byte and 4-byte ASNs starting early next year. This is pending adoption by the AFRINIC board. AFRINIC has discussed this. They have judged consensus. They’re just waiting for the board to adopt it. And it’s been accepted in all other regions.

At this point our Global Policy Proposal Facilitator Team is revving up into action. We’re pulling together all the documentation. We’re reviewing to make sure that the proper policy development process was followed, and we don’t see any issues in forwarding this up to ICANN.

The other policy we’re looking at is 2009-3. This is the policy that aims to do two things. The first is to make sure that IANA can allocate IP addresses. There are a number of small fragments that the IANA has. And right now they can only give out /8s.

Furthermore, when we get to the last five /8s, the current phase of allocations will end. We’ll immediately go into an exhaustion phase, and we’ll give one /8 to each of the RIRs. At that point the exhaustion phase has completed and IANA has no policy mechanism to follow to give out resources.

The second thing that this policy is trying to address is a redistribution of addresses from RIRs that lack them to – from RIRs that have them to RIRs that lack them.

When this policy came before this community, the ARIN Advisory Council rewrote the policy to make the returning of the address space to IANA optional.

And we believe this to be a substantial contextual change. This policy with the substantial change was – reached consensus in this region, and it’s reached consensus in three other regions with the original text.

Right now it’s still outstanding in RIPE NCC. Last meeting they had was before we accepted our policy. They were waiting to see what text we were going to ratify before they made any decision.

The important point here is the text that we put forward is significantly different from what the rest of the community has agreed to.

So this significant rewrite is problematic in terms of putting a global policy forward.

We’ve discussed this on our NRO NC calls, and our read of the LACNIC community is that the ARIN rewrite will not gain consensus in LACNIC. So it’s unlikely that if that text was put forward globally that the LACNIC community would accept it.

We sent some recommendations to the NRO NC that consensus on this policy was not likely. And we have not heard anything back. We also recommend that a new policy be proposed to the NRO EC. Again, we’ve not heard anything back.

So the question is: what are the options for this community? Well, there’s a number of things they can do. They can let this global policy just not advance, in which case it never becomes a global policy. It never becomes implemented.

And an author in this region could propose the original text that was passed in the other regions, and we could discuss it here and run it through the regular policy development process and possibly gain consensus.

Or an author could generate some new text and send that to all five regions, hoping that that would gain consensus.

And lastly, I just wanted to give a quick thanks for John for all the advice that he’s given over the years, for the ARIN board for their support and their time, for Einar and the fantastic job he does with managing policy.

That’s something that’s really important to our Global Policy Facilitator Team, because we need to go back and make sure that the policy did follow all the correct procedures; that enough time was given to people to comment on it; that consensus was reached. And the way stuff is documented in ARIN makes it very easy.

[Applause]

John Curran: Stand up, Einar.

[Applause]

Jason Schiller: And to Therese for taking care of all of our travel details.

That’s all I have.

John Curran: Thank you. Questions? The NRO Number Council report, open for questions. Okay. Wait. Wait.

Raúl Echeberría: Hi. Raúl Echeberría from LACNIC. Thank you, Jason, for the report. I didn’t understand what you mentioned about your reading of LACNIC community.

Jason Schiller: So this is actually not my read. Wilfried and Hartmut were at the meeting, and based on their feedback to the NRO NC we had a discussion after the ARIN Advisory Council changed the policy in this region. And after the policy with the changed text was accepted in this region, we had a discussion on the NRO NC of what we were going to do with that.

And one of the suggestions was to note that the policy was attempting to do two things: That it was trying to make sure that the IANA could give out resources so that they would not get stuck in limbo, and it was also trying to redistribute resources among the RIRs.

And someone had suggested that maybe we could separate this into two policies: The policy that allows IANA to not get stuff orphaned clearly has to be a global policy.

However, the redistribution of resources does not need to be a global policy. That could be a bilateral agreement between a pair of RIRs. It could be a globally coordinated policy between the five RIRs, and some suggested that we should cleave these two things and just pursue them independently.

In which case it was suggested that everyone already discussed – with the exception of RIPE, that everyone had already discussed and gained consensus on a policy for allowing IANA to not orphan space in limbo.

So we had discussed this at length on the NRO NC call, and based on what Wilfried and Hartmut had said, based on their attendance of the most recent LACNIC meeting, and based on their read of what the community concerns were, they did not think such an approach would be successful in the LACNIC community.

Raúl Echeberría: Okay. So I appreciate your comments, but I don’t know how the NRO NC can speak about perceptions. I think it is not part of the policy development process. I think we have a policy development process. We consider proposals and we take – approve some – adopt some policies and reject others.

So I think probably you can make also the same reading of what is happening in other communities. I don’t know. I don’t see the reason for mentioning that, especially that this is something that happened in LACNIC community.

So I think that’s – if the approval could be put forward for consideration so we have a formal outcome from the process if the policy is approved or not.

John Curran: Let me – Raul, just for clarity, to be sure, what you’re suggesting, I guess, the NRO Number Council has a difficult job trying to discern whether or not something is on the track to become global policy. What you’re saying is they may have jumped to a conclusion that wasn’t right and the right process would be to potentially introduce the proposal text in the region?

Raúl Echeberría: What I’m saying is there’s a process for dealing with global policy proposals and that what I see in the slide is not a part of any process. So it’s – we cannot speak about what we read from, what is happening in some community. That’s all my comments.

So it’s – I’m not saying that the proposal would happen separate or not. What I’m saying is that it seems that this LACNIC community, who is objecting the approval of this proposal, this is not the case. If somebody wants to – in fact, I don’t know if the text that was considered in a region was sent to the – formally to the other regions in order to be considered as an alternative for the former proposal. This could be an option. I don’t know if it happened.

Jason Schiller: Yes. So if you could stay put for a moment. Yes, I want to address some of those things. This is very important.

The NRO NC does not generally make global policy. We do not generally try to push global policy, shepherd global policy or reject global policy. It is our job to ensure that the policy development process was followed and, if it hasn’t, to make sure that that gets addressed.

But also, as representatives of the community, it is hoped that we are sensitive to the concerns of our communities. And it is hoped that we can share those sensitivities.

For example, when I come to an ARIN policy, whether global or not, that has been discussed in another region that I’m aware of, I hope that I can bring you some of the flavor of the discussion and the concern that they’re having in those other regions and I can help move the conversation along.

In hopes of moving the conversation along, and in terms of what mechanisms do actually exist, the mechanisms that do exist are letting this policy not advance, because right now we do not have the same text in all five regions.

We can look at the original text that was passed in three of the regions that was never discussed here and decide if we think – if we think that sort of an approach is going to gain consensus, then an author should resubmit that original text and we should discuss it. Or we should provide some new text that we think will gain consensus and submit that globally to the five regions.

That new text could be anything. It could be a global transfer policy. It could be the policy that the ARIN community passed but none of the other regions have looked at.

My advice, however, is that the policy that we passed in this community, based on conversations that were had at the last LACNIC meeting, do not seem to be acceptable to the LACNIC community.

Now, I’m not suggesting that LACNIC is being a blocker to this global policy proposal. In some ways it’s the ARIN community that’s being a blocker, because they have gone and not ratified the same text that everyone else has.

Unfortunately, in order for the global policy to go forward, it has to be the same text. And right now it is not the same text. If you want this proposal to advance, we have to do something.

Raúl Echeberría: There are more people in the queue. Can I make a brief comment? I’m not making an opinion about the proposal at this time. I’m not questioning your reading about what happened in all the process, what is right. What I object is that you cannot mention only what is your reading about what is happening in the LACNIC community. Or we experience what are the reading that we are doing of what’s happening all the regions, or so we have to limit the report to the formalities of the process. That’s all my point.

John Curran: Okay. Thank you. Two remotes, but we also have people in queue. I just want to ask: Louis, do you want to speak as chair of the NRO? I’d ask Lee to let Louis respond as chair of the NRO Number Council.

Louis Lee: Louis Lee. To provide a little context for the answer that we got over here, the question was asked: How do we provide suggestion on moving with this proposal, suggestion to ARIN, suggestion to the other RIR regions? That was redundant.

Jason Schiller: And suggestions to potential future authors of a global policy proposal in this space.

Louis Lee: So what are the best suggestions came out of the question and answer was what would the other regions do. And the only region that had representatives or the only representatives that spoke up about any region was about LACNIC. We did not get an answer about the other regions, if I recall correctly. And I got a nod from Jason. So, in that case, that’s the only data point we had to provide these suggestions.

John Curran: I guess, to ask the question I would ask of Raul, I believe the formalities of the process need to be followed. But when you have two different policy – two different texts for the same policy and no agreement, I guess the NRO Numbers Council needs to figure out where to pursue change to bring them into alignment, and they just asked the feedback of the people appointed from those regions what would be useful.

So I guess my question to Raul is: Is that the wrong way to go about it? Raul? Is that – is that the only way they know whether to try to pursue change?

And you’ve got two different sets of policies, this text and that text, A and B. They need to decide whether to get A to change to B or B to change to A to get them to line up, to decide which RIRs to engage with to consider changes. And the only thing they had to go on was be elected representatives from those regions.

Are you saying it should just be introduced to all the regions? I guess I’m trying to figure out the process they should follow.

Raúl Echeberría: I object the way in which the information was presented. I cannot accept that as – as a part of the LACNIC community that this says that the Number Council is acting based on the perception that something would not be accepted in LACNIC community.

I would like to see also what are the perceptions regarding the feasibility of a proposal like this in other regions. Not just what is the perception about LACNIC community. This is what I didn’t like.

John Curran: I see. It should address everyone’s perceptions. I understand. Thank you. Is that good feedback from the NRO Number Council? Okay. Adiel, do you want to respond directly as well?

Adiel Akplogan: Yes, just to your previous question about if there is a discrepancy between the test adopting in different regions, I think the process is to send the proposal back to the authors and ask them to look at the different variances and see how they can match them.

And I think that the policy requests that the staff work with them to do that. So I think we are at that stage now and we shall call it that.

John Curran: Okay. Thank you. I’d like to get to the people in queue but if you really need to address that.

Jason Schiller: Quickly. I just wanted to say that we did send a letter to the Executive Council. Many of the authors of the policy are on the Executive Council. And the one author that is not was on the call where we decided to send a letter to the Executive Council about this approach likely not gaining consensus and a recommendation for a new policy proposal.

So we have done that.

John Curran: Okay. Thank you.

Heather. I know you’ve got remote. Heather first.

Heather Dryden: I’m Heather Dryden. I’m from the Canadian Ministry of Industry. I have an unrelated question, if that’s okay. Otherwise you can finish off this topic.

John Curran: Of course. You have waited patiently.

Heather Dryden: You had explained that the NRO is responsible for putting forward two board members to the ICANN board. I was wondering what your process is for identifying those appointees.

John Curran: So there’s an actual memorandum of understanding that outlines the relationship of the NRO and ICANN, and in particular designates the functions that would be performed by the NRO acting as the address supporting organization.

Those functions include periodic appointment of directors to the ICANN board and includes a process by which global policy gets ratified by the ICANN board.

Heather Dryden: So do you take applications? Do you have – how –

John Curran: For the election process?

Heather Dryden: You have an election process?

John Curran: Yes. The Advisory Council runs a nominating committee and there’s a whole process. I think we can get you the URL that describes the website.

Heather Dryden: To the ICANN board? Okay. Thank you.

John Curran: Not many people know about it. We don’t wave a flag about it. It’s two seats, if I’m correct.

Jason Schiller: Seats 9 and 10.

John Curran: Seats 9 and 10 of the ICANN board are appointed by the collective address community that way.

Remote participant? Go ahead. Two? Go ahead.

Tom Zeller: Filiz Yilmaz is the RIPE NCC policy development manager. Just wants to say that RIPE is considering the text that was passed by the other regions. It’s under active discussion on the RIPE list and is under active consideration, the non-ARIN text, I guess I might call it.

And a user who identifies himself as Natim [phonetic] and affiliation of end user, also kind of objects to characterizing what LACNIC might or might not do. His exact comment was: If you want to see – if a text would be approved by a region, we need to put that text to that region for consideration, exclamation.

John Curran: Okay. I’m going to close the mics on this. Center front.

Scott Leibrand: Scott Leibrand, ARIN AC. I was at the Panama LACNIC meeting and I was at the meeting the week before in AFRINIC, in Cairo.

I on the floor of the Panama LACNIC meeting made a suggestion that perhaps LACNIC should consider something along the lines of what ARIN was considering at the time. They listened politely and decided to go ahead and vote on the proposal on the floor, which was the text.

I did not get a read that says we would not – we’d absolutely not consider this. It was just simply a “what’s on the table is better. so let’s go ahead and pass that.”

I would be more than happy – oh, I did not also get any indication from AFRINIC that they would be opposed to it or that they would be in support. I just don’t have any read on that.

I would be more than happy to work with the authors to introduce the ARIN text in other regions if they think that’s an appropriate way to go forward. And I would agree with the comments from Raul and others that if we want to know whether the other regions would support this text, we need to ask them about it.

The ARIN region has considered the original text. We considered that first. Six months later we revised it and considered the one that actually passed because the first one went down in flames.

So I think the thing that we haven’t tried yet is asking the other regions what they think of the text we passed in this region.

John Curran: Okay. Thank you very much. Jason, thank you for your report.

Jason Schiller: Thank you.

NRO Activities Report

John Curran: Number Resource Organization is the vehicle for RIR cooperation and representation. We serve to protect the unallocated number resource pool, promote and project the bottom-up policy development process, and act as a focal point for the Internet community into the RIR system. We established the ASO within the ICANN framework by an MoU signed in 2005.

Current office holders: Chairman, Axel Pawlik; Secretary, Raul; and Treasurer, I serve as treasurer. These functions rotate every year among the RIRs.

We have coordination groups that we hold between the RIRs which serve to make sure our efforts in a given area have good coordination and don’t have excessive overlap.

So the Engineering Coordination Group, chaired by Andrei; the Communication Coordination Group, Paul Rendek; and the Policy Coordination Group, also chaired by Paul.

The expenses of the NRO, and the NRO has expenses, are divided based on a formula of revenue and resources held in each region. NRO expenses include common marketing expenses: if we put an NRO booth at an ISOC or ICANN or ITU function. It also includes expenses that we do in terms of if we have a common expense in terms of engineering or communications, PR functions.

These expenses get allocated amongst – as I said, based on revenue and resources. The 2010 distribution is shown here. So ARIN pays 27 percent of the expenses.

NRO contribution to ICANN: separate from our internal expenses, which amount to – in the past year amounted to about $280,000. The most significant NRO expense is actually an NRO contribution to ICANN.

We have a contribution that we have been making since ICANN was formed. We have an agreement with them serving as a supporting organization. Our yearly contribution is $823,000 among the RIR system, again, allocated according to that formula.

And that goes to help offset ICANN’s expenses for operation. At one point it was a fairly significant percentage of ICANN. But now ICANN has a much larger organization with a budget in excess of $50 million. So it’s not a huge portion of the ICANN budget that we’re contributing.

NRO and ICANN activities: Mexico City in March 2009. The NRO was involved in consultation with the GAC, the Government Advisory Committee, of the ICANN. We gave an NRO update during the public forum. We participated in SOAC joint meeting and we had discussion with ICANN about the NRO contributions.

In Sydney we were at the ICANN meeting. We met with the ICANN board. We were involved in meeting the CEO candidate and gave an NRO update.

We were in the Seoul meeting, and we had a consultation again with the GAC advising them about issues with the Number Resource System, the depletion of IPv4.

The NRO has been very active in the Internet Governance Forum. The Internet Governance Forum is a multi-stakeholder group formed out of meetings with the United Nations and WSIS, World Summit on Information Society. It is a place where policy issues regarding the Internet can be discussed with many different participants.

They have an advisory group which helps set the contents of the meetings. Raul is our representative in those. The last meeting was in Sharm el-Sheikh, Egypt, and the NRO has always had representatives there. We were involved with both a booth there as well as participation on many of the workshops.

We had a number of folks, including Bill Woodcock from our board. John Sweeting came out from the ARIN region to help with the booth management. So we’ve had very strong representation, letting people know how the RIR system works.

We provide a contribution through the NRO to the IGF secretariat, which is important because by having the IGF there, it’s a good forum to have these issues discussed. We’d rather have them discussed in an open multi-stakeholder organization than discussed in perhaps closed meetings among governments that we wouldn’t necessarily be able to be a party to.

So we consider the IGF an important open participatory organization for us to be involved in.

ITU: the NRO does serve as some of our coordination for the ITU, including providing Internet number resources statistics to the ITU members who were completing a survey that the ITU asked them to complete.

Participation in ITU’s Telecom World Summit, which is a meeting of very many telecommunication organizations worldwide. And also meeting with the ITU to discuss and understand their issues as perceived with IPv6 address management.

When we get involved with other international organizations, we use the NRO as a coordination body. So we’ve also worked with the OECD, having joined the Internet Technical Advisory Committee and contributed to some of their publications and technical meetings.

Ongoing activities for this year and last year: obviously RPKI, the issuing of digital certificates that attest to the issuance of number resources. We’d like to have one well-coordinated RPKI system that’s interoperable and doesn’t require vendors to support many different types of certificates or many different types of trust models.

So we’ve been working on that engineering coordination. We’ve been doing quite a bit of joint communications and outreach. When we go out and talk to people, the first thing they ask is: How many IPv4 addresses are there? How many have you issued? How many IPv6 addresses are there? How big is that?

We don’t all need to independently answer the same questions when the facts are common among the RIRs. So we have the NRO staff work on it, which is our staff effectively assigned to the NRO. And then when we go to publication, we share the costs through the cost-sharing formula.

So addressing IPv4 and IPv6 issues and also in IGF preparation, obviously.

We do hold a retreat. We hold a retreat so that we can actually get the staff face to face, the executive team and, for example, the CCG, ECG and PCG groups, and that’s sometimes more effective for e-mail, for working out some of the more contentious coordination issues.

Retreat outcome. It was instrumental in us being ready for the ITU IPv6 working group. Our strategy and communications were laid out at the retreat.

We had agreement to continue the IGF secretariat support. We laid out our RPKI roadmap in terms of coordination and development. We have another retreat coming up in the July/August time frame.

That’s the full NRO activities report.

I guess I’ll take questions at this point. Lee.

Lee Howard: Thank you, John. Lee Howard, ARIN Board of Trustees. You used a lot of acronyms. A lot. Most of them I’d heard before. A couple of them you didn’t define before you used them. I know what a GAC is, but I’d like to hear you say it out loud.

John Curran: Government Advisory Committee.

Lee Howard: One of the advisory committees of ICANN. The one I hadn’t heard before was SOAC.

John Curran: SOAC is Supporting Organization –

Lee Howard: Supporting Organization Advisory Committee of ICANN. What is that?

John Curran: The SOAC is – actually, I’m not even sure if it still exists – ICANN instrument for getting input into the board from its supporting organizations.

ICANN has a number of supporting organizations, most of them focused on DNS, but the SOAC exists. And we had a consultation with them where we wanted to talk about things like the IN-ADDR DNS and DNSSEC.

Lee Howard: So the SOAC is distinct from the ASO AC.

John Curran: Yes. The ASO AC is our advisory organization.

Lee Howard: Not according to ICANN.

Louis Lee: Can I help?

John Curran. Yes. Go ahead, Louis.

Louis Lee: So the “SO” in SOAC is Supporting Organization. So we are ASO, the address point, and there are other SOs around. And there are also other groups that are called ACs. So ICANN just refers to the collective lot of us as SOAC.

And the chairs of these groups –

Lee Howard: Can I see a Venn diagram? Because I’m not keeping up here.

John Curran: If that doesn’t answer your question, I can point you to the ICANN website. There is actually information. ICANN has a lot of instruments within its organization, and ASO AC is what we serve as; our NRO fills that role. The SOAC is a union of the supporting organizations, us and others combined.

The floor remains open for questions. Remote? No. Thank you very much.

RIR Update - LACNIC

Raúl Echeberría: Thank you, John. I will take advantage of this opportunity to make a comment about the NRO report. You say that I am a member of the Multi-stakeholder Advisory Group as a person of the NRO, but I would like to say also that Cathy Handley from ARIN is also an active member of the Multi-stakeholder Advisory Group of IGF. So I’m not alone there.

Okay. Some news from LACNIC: We are currently 21 people, full-time employees. FTE means full-time employees. We are hiring more people here. So we have some changes in the staff. Some of you know Ricardo Patara. Ricardo Patara used to be the CEO of LACNIC for many years, since the beginning. He moved now to the Brazilian National Registry. He lives in Sao Paulo, so it’s more – it’s better for him to work in Brazil.

So we are facing the challenge of hiring, of having a new CTO. We have completed the hiring process as we have hired Arturo Servin who is a Mexican that is currently living in the U.K. He’s moving to Montevideo for taking this position in the next weeks. So we are waiting for him with a big amount of work on the desk. And surely you will have the opportunity to meet him in the next meetings.

As we have also created a new position that we didn’t have before. This is the human resource manager, as we hired Felix Fernandez. And so there will be now – in RIPE NCC meeting there will be a meeting with the human resource manager from both RIRs, so, America, you will have the opportunity to meet Felix there.

So we are growing in staff terms. And we expect to have 25 people before the end of the year. But also we are growing in other – regarding other indicators, we have completed 1,200 members in the last week. It’s a huge number if we compare that with the 150 that we had when LACNIC started to work in 2002.

So it’s a big challenge. Thank you.

This is the membership evolution. So it’s normal and very similar to what is happening in other RIRs. It’s not too much magic in that.

Oops. This is not very good. This is the problem of using free software. I use free software, but every time that I send, try to export to a more commercial format, the file suffers some changes.

We have some policies under discussion now. Some of them are related with IPv6, the changes in assignment policies and also changes in the way that – in the requirements that we have for the announcements of the IPv6 blocks that are allocated to customers.

We are still considering a proposal for transfer of IPv4 addresses. We have a change proposed that are under consideration for direct allocations. It is very interesting, because we have a policy for direct allocations that these companies that cannot demonstrate the previous use of the IP addresses.

So it is the case, for example, for that the centers are new, and they were – that they start from zero, and so they have to demonstrate that they are making investments and so they have the right to receive the IP addresses, even if they cannot demonstrate that they have been using addresses from one ISP, one option provider.

But this proposal required that the organization would be multi-homed for receiving addresses under this policy. But the problem that we are facing in some countries is that in some countries there are monopolies – or not monopolies but open markets but that act in – in fact act as monopolies.

So some of the – some companies have problems to be multi-homed in some countries. So we are making some changes in this policy.

And there are also two proposals that related with the policy development process. You notice that that’s – in the LACNIC region we have three major languages that are spoken in the region. There are many more languages that are spoken in addition as languages, and also French, some Papiamentu and other languages, but the three main languages are Spanish, English, and Portuguese.

And there is one proposal for having – we currently have two policy chairs that are two people that are linked by the community for policy development process. And there’s a proposal for having three chairs, as one – each of them coming from one of the biggest language communities.

So there is other proposal for implementing electronic mechanism for electing the chair of public forum that currently selected in the face-to-face meeting.

Engineering projects: It’s not very different of what is being done in ARIN’s. We are very committed with the development of RPKI. We have been working in that process for two years, almost two years.

We took the software that was developed by RIPE NCC and we have developed all the adoptions, the customization for being used together with all the LACNIC systems, as we have developed also all different things for the system and the interfaces, the user interfaces, as we’re ready to start with phase one, is to work in an experimental way from LACNIC XIII that will be held in May. It would be announced during the meeting.

As we are working also in DNSSEC, we have had more delays than other RIRs, but I think we expect to be ready for signing a response in the third quarter of this year.

We are working, and we have been working for a long time in a new registry system that’s based in an EPP protocol. It will provide some benefit, order of benefits for our members. And also it will permit to work more, in a more integrated way with the two national registries we have in our region. I mentioned that, I think, yesterday.

Regarding IPv6 in 2009, we held meetings and training in 11 countries. Those are – those were activities organized by LACNIC. In total, we trained 879 people in 2009 in our own activities.

We have a total – in total we have trained since 2005 more than 5,000 people in IPv6 in the region. And so 3,500 in more generic aspects of IPv6 and instructional training and workshops and 100 – 1,500 in hands-on workshops.

So we also remark that because we always say that probably one way to see the evolution of the adoption of IPv6 is to analyze the evolution of the number of allocations in the region.

But I think that we have made very important progresses in creating the capacities for dealing with the transition to IPv6. So probably some companies are not moving or not adopting IPv6 today, but this is just because they think that it is not the time for doing that yet. But they have the capacities for dealing with the problem when they decide that it is time to go to IPv6, and this is a very important thing that permit us to be more relaxed in the sense that we think that the region will be ready for the transition.

In 2009 we started a new project, this Project AMPARO. It’s not an acronym. It is – it’s just a name. And this is a project that the main objective of the project is to create more CSIRTs in the region. For doing that one of the things that’s being done under this project is to create materials, training materials for being used publicly, and the materials are being elaborated in a cooperative way among the many people in the region.

So we have also – we have a first version of those materials and we are organizing some workshops for forming – for future trainers in those areas.

It is – many people is paying attention of this project because this security is something that’s very important for the community and for many stakeholders, including governments. So it’s the attention of what’s happening, and I think the project is going very successfully.

As we have also organized two workshops this year: one in Montevideo and one in Quito, Ecuador.

We continue with one of our main programs; that is, FRIDA. It’s a program for supporting – through small grants supporting research projects in the region related with ICTs and the Internet. So we have completed the 59 projects funded by this program for a total of $1,200,000. This is a program that – it’s a partnership between LACNIC, IDRC from Canada, which is very good to say today because we are here.

And also the Internet Society: we have – by the way, we have a very strong partnership with this organization. IDRC, that is a cooperating agency from – depending on the Canadian parliament that is very active in promoting ICTs in Latin America. And we have a very strong partnership with them.

Regarding public affairs: as a member of CITEL, this is a body of the organization of American States, we organize the workshop on interconnection at low cost in Bariloche, Argentina, last year. It was very good, very nice experience.

And I think that I didn’t mention here, but recently the general assembly of CITEL was held in Mexico in the first week of March. And I think LACNIC and ARIN worked together and did a great job as we – in fact, we do a great job in the working together governments in the CITEL environment offering training as preparing papers, giving presentations, helping them to understand some issues that are not derived from our scope of work, and I think that’s why we are being recognized by governments for the work that we are doing.

And it was reflected in a resolution that was adopted by CITEL by the general assembly that is the maximum body of CITEL in this meeting in Mexico, March, where it is recognized that the role of the RIRs in creating regions and communities and also in improving the equity of the allocation of IP addresses in the world.

So I think that’s – the RIRs are sometimes attacked by – just by this concept of the lack of equity in the locations of IP addresses.

What we have from CITEL is the recognition from the governments of the Americas. The RIRs have been doing a very good job in this regard. They think it’s very important, and ARIN and LACNIC have been working together in this environment. This has been a very good experience, very positive experience of cooperation between the two RIRs.

Last year in Egypt LACNIC was very active organizing workshops. Besides the workshops, we organized with the NRO. We organized two workshops as LACNIC. One was a workshop just explaining how the Internet addresses management systems work, as we have commenters, presenters and commenters from different stakeholders, and also the outcomes of that workshop were very positive. And the other was about public policy for interconnection and low cost that is a matter of importance in our region. So it’s an issue in which we are active because it’s of interest to the community.

We have created also last year – Bobby Flaim commented something in his presentation that we have also a government working group in LACNIC. It is not exactly the same. It’s not so inclusive for law enforcement; it’s more generic for discussing about many, many things that are of interest of LACNIC and also of governments of the region.

Currently we have 52 persons, officers from 21 governments that participate and are subscribers to the list of the working group. And we will hold the third face-to-face meeting of this group in Curacao on Monday, the 17th of May.

Important things will be discussed there like what’s happening with – we are in touch with governments about those issues. But we will have an opportunity to discuss face to face and make an evaluation of those processes and also continue receiving the feedbacks from the government and also the expectations of the government. That is a good channel of communications, to know what are those expectations and look if those expectations could be fit in the LACNIC community.

Through the +RAICES Project, it’s a project for disseminating, for deploying root server copies in Latin America. And we just installed the sixth copy of the root Server F in Sint Maarten in Netherlands, Antilles in July of last year. We will sign an agreement with the HN ISP for installing the seventh copy of the root Server F in Haiti. That will happen in the next couple of months.

Finally, all of you are invited to participate in our meetings. I’m very sorry that we cannot provide some exotic venues for you and nice places for visiting. But you have to accept that the invitation for attending the LACNIC meeting in Curacao; I think that you will find something of interest there. It’s a nice place, very nice. The only problem with visiting Curacao is that you don’t want to come back home.

But besides the place, I expect that we have interesting discussions there. So if you are there, we will be very glad to involve you with the discussions.

Thank you very much.

John Curran: Thank you.

[Applause]

Any questions for Raul and the LACNIC update? Okay. Thank you.

DNSSEC for the Root and ARPA zones

Dave Knight: I’m Dave Knight. I work in the DNS operations group at ICANN. I’ve got two sets of slides to go through this afternoon. The first is DNSSEC for the root zone, and the second is DNSSEC for ARPA and the ARPA family of zones.

DNSSEC in the root is a joint – is a project which is collaboration between ICANN, the NTIA and VeriSign. ICANN’s role in this is – as the IANA functions operator is the holder of the key signing key. Also ICANN accepts requests from TLD managers to update DS records in the root zone.

The NTIA authorizes changes in the root zone. And VeriSign, in the role of the root zone maintainer, implements those changes, creates the root zone and signs it.

Additionally, they create and maintain the zone signing keys which are used to sign the zone. Those zone signing keys are brought to key ceremonies where ICANN exercises the key signing key to sign those zone signing keys.

The goals of the deployment are that this be very transparent and open. To that end we’re trying to do as much communication as we can, showing up in forums like this to explain what’s going on.

There are some anticipated issues with the deployment of DNSSEC at the root. First and foremost, among those, is that there’s a significant community of resolvers out there in the Internet, which by default ask for DNSSEC information when querying.

Until the root zone was signed, this wasn’t an issue. Once it’s signed it means that those servers are going to start to get bigger answers than they might be expecting. Those servers, which are behind bits of the network which can’t pass such big answers, might then have problems.

During the deployment, if we saw problems and had a need to roll back the changes, we would have run into problems if a significant community of validators had formed; i.e., if people had started to configure the root trust anchor in the resolver.

So to avoid that, to avoid running into intermediate problems, we deployed incrementally. So the signed root zone has been turned up on root servers, one, two, three at a time, but not all of them all at once in a flag day.

And to stop a community of validators forming, although the root is signed, it can’t be used for validation, because the keys which are published in the zone have been deliberately and obviously broken.

This is what one of these keys looks like. With the naked eye, it’s plain to see that it will not work. And anyone who does try to configure this really just has themselves to blame. As we go through the deployment, measurement is a very important part of this. Most of the root operators are gathering data around each of the transition events. A transition event is when this deliberately unvalidatable root zone is turned up on one of the root servers. And each time that happens we capture all queries that arrive at all of the root servers and pull them to a central location where they can be analyzed so we can see if there’s changing patterns as we turn up this on each server.

On the other side of the root signing effort is how keys from signed TLDs will get into the root. This is the IANA part of things. And how it’s likely – this hasn’t been finalized yet. The discussion is still going on within the project. But it’s very likely that the way that TLD managers interact with the IANA today to make changes in the root zone is how they will do this tomorrow to add DS records to the root.

We expect to be able to start accepting DS requests from TLD managers anytime now with a view to having those in the root zone before signing. The project has a Web page – that’s www.root-dnssec.org – where the status updates is posted. All the public documents related to the project are posted there. All presentations, such as this one. The slide decks will be published there. And contact information where you can send feedback is also available on that site.

The root was signed internally at VeriSign in December of last year. And it was then made available to the root server operators so they could pool it and do testing. This is the deliberately unvalidatable root zone. Since then, since January, we’ve been incrementally rolling this out to more of – more and more of the root letters. Initially L root changed in January, then I think A root was next in February. And then since then we’ve been in bigger and bigger groups, such that at this point the only remaining letter to make the transition is J root, which we’ll do next month. As I mentioned already, the documentation related to the project can all be found at www.root-dnssec.org.

All testing regarding the deployment of the DURZ root zone has been complete. That involves testing that the measurement would work; that we could gather data around these transitions and transmit them to work.

The KSR/SKR exchanges. What that means is where – when VeriSign creates a batch of zone signing keys, which they’ll use to sign the zone, they send them to ICANN in a KSR, which is a document which contains a bunch of keys. That is then taken to a key ceremony where the key signing key is exercised to sign the keys in that, and that is then transmitted securely back to VeriSign in another document called an SKR. I think that stands for key signing request and a signed key response.

And before deploying the DURZ, because the DURZ itself was a new technology being introduced at the root we did some testing against known resolver implementations to make sure these strange keys wouldn’t cause adverse effects for those, and that will pass without any problems. As I said already, all of these letters, with the exception of J, are now running with DURZ, and J will make the transition on the 5th of May.

So far as this DURZ zone has been rolled out we haven’t seen any major shifting, shifts of traffic away from DURZ letters to non-DURZ letters, which was the thing that we were looking for, which might demonstrate that there were some resolvers which couldn’t reach root server 7 in the sign zone.

Last week, I think, we announced a process for members of the community to apply to be trusted community representatives. What that is, as one of the goals of this is to be very open, we want members of the community to take part in the ceremonies where we create and exercise the zone signing and key signing keys. More information about that is on the root-dnssec.org website, and also there’s an application form where interested parties can make a statement of interest if they want to take part and be a trusted community representative.

As I mentioned already, there’s feedback information on the website. The main place to send that is rootsign@icann.org. That goes to people at ICANN, VeriSign and NTIA. So if you have any comments or questions, that is the place to send it.

John Curran: Do you want to hold questions until you have done both?

Dave Knight: Yeah. Okay. In addition to the root zone, the ARPA and its second levels are also being signed. ARPA was signed alongside the root internally at VeriSign in late 2009 and was distributed to root server operators for their testing, the ARPA zone also being served on the root servers.

Since March, that’s been published. So since then ARPA has been signed in the wild. And what was considered a test deployment, that test is now considered to be complete, and ICANN is submitting a test report to the NTIA proposing that DNSSEC and ARPA be considered to be in full production.

The subject of this operation, though, is about ARPA’s children and DNSSEC for these zones. That is the complete set of second levels under .ARPA. Currently only the e164 zone is already signed. That was signed by RIPE NCC in 2007. They have told us that they intend to submit a DS record for that for inclusion in the ARPA zone in June.

IN-ADDR.ARPA, because it has different dependencies on it than the other zones, has been considered on its own. And there’s a proposal with the NTIA now to – well, first and foremost to migrate it, to redelegate it. Currently IN-ADDR.ARPA is served by – on the root servers. So the proposal proposes that this be redelegated to a set of servers operated by ICANN and the RIRs. And following that the IN-ADDR.ARPA zone will be signed.

The other children, there’s a separate proposal with NTIA. All of these zones are currently operated by ICANN. And this proposal is that they be signed also. The signing of these zones will be done on infrastructure run by ICANN currently used to sign icann.org. This is built on OpenDNSSEC. We have redundant signers at each facility, and we have facilities on the East and West Coast of the U.S.

We’ll sign using the same parameters as is used for the root in the ARPA zone, so that’s NSEC and RSA SHA-256, which that KSK rolls over very three months, and an annual KSK rollover. The trust anchor for .ARPA has been published in IANA’s ITAR since March. The trust anchors for the ARPA children will be sent into the ARPA zone upon the successful conclusion of testing. The state of it today is ARPA signed IN-ADDR.ARPA. We have submitted a proposal to sign and expect to sign it this year. The other ARPA second levels, we expect to do a test signing deployment of that during this quarter.

Any questions?

John Curran: Microphones are open for either presentation. Mark.

Mark Kosters: I have two questions. My name is Mark Kosters, ARIN CTO. So the first question is dealing with the root and the priming queries. There – I guess how many of those roots are actually participating in logging the results and that third parties can actually analyze them?

Dave Knight: We’ve got – there’s a couple of mechanisms for collecting data. One of those is an ongoing collection, which collects only the priming queries. But logistically it would have been very hard to collect all queries throughout the whole course of the project.

So we’re collecting priming queries I think at 12 of the 13 root servers and sending those to since OARC all the time since the thing started in December. And so OARC members have access to that data.

Full query capture we do just around the transitions. It was a table with when each of the groups of servers transitioned to the DURZ, and we do a query capture there of 48 hours around the maintenance window. And, again, 12 of the 13 are contributing to that.

Mark Kosters: So one is not participating. Is there a reason for that?

Dave Knight: I think you should ask that one.

Mark Kosters: Okay. Okay. Next question. Is that – it’s kind of related to that question. CAIDA actually has done a great job of analyzing these transitions in terms of let’s see what the sort of traffic swings are. And I’m personally worried that we just don’t have enough instrumentation to actually see the swings. And when the J goes, all of a sudden you’re going to see some outages. Now, you have seen some already; is that correct?

Dave Knight: I think there’s been one comment from one person who has observed an outage, but we weren’t certain that that actually was related to this and not just their own configuration.

Mark Kosters: Okay. Okay. I’ll do my next question after Geoff here.

Geoff Huston: Geoff Huston from APNIC. Following on from that, what has happened here is that the UDP response size from a DNS query has now become significantly larger. And this raises some issues related to IPv6 transport, which is also now part of the root system, as I understand.

Have you seen or observed instances where the UDP response in v6 has failed due to that combination of excessive size and the inability to fragment?

Dave Knight: Not that I know of.

Geoff Huston: Have we been looking over there at the roots for such circumstances?

Dave Knight: I don’t know. Oh. Mr. Vixie.

Paul Vixie: We are collecting the kind of data that could be used, to answer that question, as part of the DITL effort that goes around all of this. DITL, by the way, is a trademark of kc claffy, a frequent member of this. Not a trademark, but she did come up with the name. But, anyway, we have that data. If you would be interested in looking at it and telling us if it means what you’re asking, you should contact DNS-OARC and say “I want to see the data so I can figure out what’s going on with the v6 and fragmentation,” and there you’ll be.

Geoff Huston: Certainly from APNIC’s perspective with George and myself and the R&D team, we are interested in this. The question was at this point directed to whether IANA is actually looking at this at this point, and, if not, then we’ll happily go and do our own investigations as well and see what we can find. Thank you.

Dave Knight: So far OARC has been doing analysis of the data and haven’t reported problems.

Geoff Huston: Whatever that means.

Dave Knight: Right.

Chris Grundemann: Chris Grundemann. Geoff, you might end up walking back to the mic. How would they know? They packaged up a packet and they shipped it. They didn’t – they’re not expecting a response back, right?

Geoff Huston: Repeated queries.

Chris Grundemann: But they may not see it because it may go from J to F to A to –

Geoff Huston: That’s why you need all the roots and you actually need a relatively comprehensive data set and a fair level of instrumentation. But I believe it would be possible to find the trace of a problem.

Chris Grundemann: Right. So I guess what I’m asking is – my question was: How would they know? And I was hoping the response would be I’ll write something up to them so they’ll know how to know.

Paul Vixie: So the DITL collection is comprehensive in that sense. It is all the root servers except the one that nobody wants to speak the name of. And as long as that one isn’t responsible for too many follow-up queries, then I believe the pattern you’re looking for is in the data that we have.

Geoff Huston: Thank you.

Mark Kosters: Mark Kosters, ARIN CTO again. The other question is signing IN-ADDR.ARPA. Certainly would like to see that soon after we do the transition, because I really don’t want to do a key roll for the /8s that we have.

John Curran: Any other questions?

Rob Seastrom: I hate to pull you back to the mic, Mark. But your last comment scared me. Why would you hate to have to do a key roll? Because testing your key roll procedures is part of rolling it out.

Mark Kosters: It’s actually sort of following that adherence to the documentation we put out. RIPE has a six-month key roll, if I remember correctly. We purposely made it a year with the hopes that IN-ADDR.ARPA would be signed by then so we wouldn’t have to do the key roll.

We don’t have to have to do it, but then we would have to change the documentation. But I really don’t want to do it based on things that Geoff has seen that – you haven’t – did you talk about it here? No, you didn’t talk about it here.

Rob Seastrom: Oh, oh, oh, I want to hear this.

Mark Kosters: You do?

John Curran: But I’m not sure this is totally relevant to the entire community. It might be something worthwhile for Geoff and Mark and R.S. –

Owen DeLong: No, it is.

John Curran: It’s only relevant if we go through – okay. If the community wants to hear, go ahead, Geoff. Everyone hold on to your seats here.

Geoff Huston: In January what we noticed on the secondary DNS servers we served for RIPE NCC was the traffic jumped astronomically, jumped from below about 5 megabits a second up to 30 instantly and stayed there for many, many days. We wondered what it was. We’ve actually found out that it was a result of deprecating the old key in a key roll.

What happens is that folk out there load up keys into their local trust anchor set and life is fine while those local keys can validate responses coming from signed zones. But if those folk – there don’t need to be many of them – don’t update what they received and simply run with the stuff they got from their RPM or their distribution, when there is a key deprecation event, their local trust anchor keys will not validate the response.

Older versions of BIND than the current release will persistently search every possible validation path to see if there’s a way in which the response will validate against their local trust anchor.

When they fail, they will not cache the answer of failure. So every single resolution they get will exercise a combinatorial explosion of queries so that a very small number of folk with outdated local trust anchors can create a massive amount of traffic on the server.

The reason why I think Mark was a little bit reluctant to actually have to do a roll in a deprecation before having a hierarchy is if there is a distribution set with Mark’s current keys in it out there in the wild and folk do not update, and some of them won’t, then there will be an influx of folk using the less than completely current version of BIND and Unbound on traffic into those servers. But I think Paul can give us some updates there on what I mean by the current version of BIND.

Rob Seastrom: Before Paul does that, can you repeat the traffic numbers slowly; because I wasn’t sure whether I heard that it went to 30 or to 230.

Geoff Huston: It went to 30 megabits per second.

Rob Seastrom: So a six fold increase.

Geoff Huston: The number of folk who were aberrant was extremely small. The query rate was astonishingly aggressive. They have rolled every six months. When we looked back we found similar spikes. And each time, as more and more folk play with DNSSEC, it jumps by about a factor of 10 in terms of the received traffic. We’re waiting for the June roll with excitement.

John Curran: Two questions. Actually not for you; it’s for Mark. Mark, when is our current key roll due to happen?

Mark Kosters: Our current key, if we follow the same structure –

John Curran: If IN-ADDR doesn’t transition and we allow a little wiggle room to make sure we get it right.

Mark Kosters: If we allow a little wiggle room to get it right, it’s scheduled to expire in September. But we can keep it going.

John Curran: At present we have all – I think we finally completed all of the paperwork necessary for IN-ADDR transfer. ARIN has been doing this forever. IANA nicely has offered to do it. And I think we’ve gotten the NRO to sign off and we’ve got the SOA to sign off, so now it’s just getting the data. And that’s really not for you to answer.

But I think it’s compatible with getting it done before the roll, the last time I checked with the IANA team. Otherwise we’ll roll with the traffic. Mr. Vixie.

Paul Vixie: Thank you. So switching hats for a moment, speaking from my day job, Internet Systems Consortium, the BIND folks, the – all of the recent versions of BIND – there’s 9.7.X and a 9.6.X and so on – will behave properly, which is to say they will not spam Geoff’s servers or your servers or any other servers if they are given an incorrect static key.

So we certainly regret that bug. On the other hand, the particular set of servers that was pummeling Geoff’s server were not only running the older version of BIND that had that bug, they were running a set of, I guess Fedora packages, which I guess included a bunch of static keys. And we have really worked hard in terms of outreach to discourage RPM packagers from including static keys, because we really don’t think that those are likely to be upgraded fast enough.

So the behavior of having the wrong static key now with the modern version of BIND is that all of your resolutions will fail, which is I guess better.

[Laughter]

So you don’t want those static keys, is I think what I’m trying to say. You should be running current code and we should ship better code. But it’s also very important that you don’t install static keys and then forget about them. RFC 5011 was written for a reason.

I also have some Jabber Text on my screen from Duane Wessels who until recently was at DNS-OARC. He’s now at a day job of VeriSign but still takes care of DITL and a bunch of other things related to OARC. And he said that he can’t get on the official Jabber Room for whatever reason, but this time all 13 root nameservers did submit data for the DITL, and we actually have 13 roots’ worth of data for the most recent set of DURZ transitions.

John Curran: Excellent. Far right microphone.

Michael Richardson: Michael Richardson. Somewhere around here – not today, but Paul Winters is the guy that did the RPM packaging. He was called away today. But you’ll probably see him tonight if you want to take your grief out.

But what he did tell me last night was that – two things. First, you realize that the Red Hat Fedora pack distro actually has a shelf life of six months. You actually can’t install keys older than six months because they’re just not on the net. So they actually didn’t put them in their enterprise stuff because it has a longer shelf life. That’s the first thing to realize. So you won’t have that, won’t have really old keys.

The second thing is that they’ve actually pulled all the static keys out. There is one static key in. I believe its dlz.isc.org. So that’s the one that’s there. Six or eight months ago I don’t think there was much in the DLV at the time, and that’s what Paul actually much preferred, to go that way.

So the prediction is right. Nobody can install an older version of Fedora anymore, and anyone who does install something will get the DLV. So, Geoff, actually you should see no spike should be the prediction at this point. So that’s the interesting question, will it happen.

Paul Vixie: And to that end, it’s also the case that when Mark begins rolling his IN-ADDR subzones, he should see no spike. So we’re really thinking this whole spike problem is a thing of the past.

John Curran: Okay. Any other questions? Closing the microphones. Okay. Thank you, Dave.

[Applause]

Okay. Next up we’re going to – let’s see. Yep, we’re definitely going to move ahead. Okay. I’d like to do the AC On-Docket Proposals Report, and that will be the chair of the AC, John Sweeting.

AC On-Docket Proposals Report

John Sweeting: Good afternoon, everyone. This is going to be really fast, because I’m already in Heather’s doghouse and I want to make sure she has plenty of time on the open mic today.

We have one proposal that’s on the docket right now that didn’t make it to this meeting. It is Policy Proposal 109, Standard IP Reassignment Registration Requirements. It was submitted February 4th by Chris Grundemann. And Cathy Aronson and Mark Crandall are the shepherds for it.

It was accepted on the AC docket February 18th. Revised by Chris on February 9th and then again on March 4th. I think he was – revised using input from the community on PPML. He also did a presentation – a good presentation, by the way. Thanks, Chris – at the open policy hour on this past Sunday.

And it is currently on the AC’s docket. Thank you very much.

John Curran: Any questions? Whoa, whoa, whoa, John. Come on up here.

John Sweeting: There are no questions. It says “thank you,” not “questions.”

John Curran: I should end more of my slides that way.

[Laughter]

We have a “thank you” at the end of the table. Go ahead.

Lee Howard: Lee Howard, ARIN Board of Trustees. You’re welcome.

John Curran: Okay. Thank you very much, John.

[Applause]

Okay. Catching us up very nicely. We have an Update on the Canadian IPv6 Task Group. Very Nice. Yves is here.

Update on the Canadian IPv6 Task Group

Yves Poppe: Thank you, John. Thank you, everybody. So I have no controversial proposals, so there will be no questions or anything like that. What I wanted to share with you today is what we have been doing in practice here in Canada with our famous IPv6 of course, which we’ve been allocating a long time, and it was in the context of ISACC. I don’t know if you’re familiar with ISACC, the ICT Standards Advisory Council of Canada, which is a joint creation of Industry Canada and the industry sector.

So basically the way it all started is that at one of the ISACC plenaries in the last year, the primary theme was IPv6 at that time. I gave a presentation on IPv6. Then there was a big discussion. The consensus was that Canada had not taken any leadership role and was getting behind – as you know Canada has one neighbor to the south; that small country called the United States – and that they were moving ahead.

So the plenary decided we should create a task group. So the deliverables of the task group were to explore the options, obviously, identify the benefits and challenges, the actions to be taken by the private and public sector, and policy directions for Canada.

So why emphasis on IPv6? Again, simply to help ensure the Canadian competitiveness in the telecom industry. And obviously the telecom sector lays golden eggs. It’s still 1.3 trillion in the OECD only.

How did we proceed? We solicited participants. We had about 40 participants in the task group, including all the major carriers and ISPs – Bell, TELUS, Videotron were there – the manufacturing side, small companies, government, CRTC, the military.

Work started on June, 15 meetings, six of them face to face. Recommendations were presented at the ISACC plenary in November. Marc Blanchet and Ed Juskiewicz decided – or were appointed, in fact, to write a final report, which is a 66-page document which you can find on the ISACC website. Then this year in March there was a special session convened to approve the final report. It was approved, so the work is completed, and we consider that the task group can be disbanded.

Of course we’ve been discussing that, but the exact date it will run out, we don’t know. And in fact we shouldn’t care. It’s totally immaterial. I’m often asked as a service provider what my take is. I say I absolutely don’t care because my revenue is Sigma v4 plus v6. I provide both. So the transition speed is immaterial.

Now, can you spare a couple of addresses? Some of you went probably to the BII China IPv6 summit two weeks ago in Beijing. They say they just need about 34 1/2 billion addresses in the next five years. So peanuts. Indian government wants to roll out broadband in all their villages, and there are a lot of them. About 630,000. So you can expect a lot of addresses there, too.

Now, some in this debate said we have enough addresses, can’t we wait a bit more? And of course you can procrastinate until the end. The risk is loss of competitive edge. If someone moves first, the big risk in our opinion is the more you wait, the more you risk to have all of a sudden capex increasing at the end. It’s like pushing snow in winter in Canada.

So the growing urge to move can be detected. People get edgy, thanks to John, who sends letters to all the CIOs. They said, what the hell is going on? So Darwinian forces are at work. People want to survive. Late movers are coming, and of course GDP and telecom are closely linked. And in fact one of the key factors is at the second session in March we invited John as keynote speaker, and of course he did a good job and got everyone excited.

Now, seven recommendations. All good things come in seven. There are seven sins. And here we have seven recommendations.

So one for government. Specify IPv6 support in your procurement. CRTC, our beloved regulator. You have to have relevant telecommunications decisions in favor of IPv6.

ISPs, obviously you have to deploy. Industry, you have to supply the goods. Content providers, make it accessible. A lot of discussion on setting up a center of excellence. In fact, most of the discussions were on that point.

And then seven, of course, use government programs and support for the IPv6 transition, because you have always people around who are trying to get some government money to do some things.

Government as a stakeholder. Quite obviously. CRTC is a stakeholder. Here the interesting thing is point D, to promote Canadian transmission facilities, that’s E, and promote ownership, because you know we have quite a major debate going on foreign ownership here in Canada. So that’s the reason.

ISPs as a stakeholder. Content providers. Content providers are an interesting story, because they are the first ones who will suffer if we run out of addresses. And if the Internet gets fragmented.

Industry. Quite obvious. And we’re waiting for industry, including our preferred suppliers to be ready.

Government programs. There are some programs. Of course, some people wanted the Canadian government to follow the old Japanese example where you got a tax break if you upgraded your equipment to be IPv6 compatible. I think it’s a little bit late for that.

Center of excellence. Everyone wanted to have a Canadian center of excellence. But nobody wanted to put up any money. So Industry thought government would put up the money. Government thought that Industry would put up the money. And everyone looked at each other and they think it’s still a virtual center of excellence.

[Laughter]

Correlation to that, a lot of discussion on what profile we should define, because if you say we have to be IPv6 compatible, what do you follow the IPv6 foreign profiles or the NIST profiles. In fact, we favor the NIST, the National Institute of Standards, profiles.

Some of the manufacturers, interesting enough, they were not too enthused by the idea, because they were, I think, a little bit concerned that, as they put it, the customers, meaning the government, would put out unreasonable demands for IPv6. In fact, meaning, but they didn’t say it out loud; more equipment is not ready to support all the features you would be asking for. So please make your transition compatible with my product development plan.

Any concrete results so far? I think the one thing I had set out, there’s a major project coming out in Canada which is called GENS, the Government Enterprise Network System. That’s on the federal government level, and there the idea is to concentrate the existing 110 or 120 different networks into 10 or 12.

And obviously the question was do you specify IPv6 or not in the GENS specification, which is not out. There was a lot of turning around. And in the end they said, yes, IPv6 will be mandated. So that’s in fact, I think, in itself a good result and sufficient to have had the task force.

Canadian ISPs. They’re still very polite with each other. And they said please go first and I will follow. Yes, please. I think I will see some movement very soon. Especially with Comcast in the U.S. on the cable side and now that we have Verizon on the teleco side.

Now, an interesting phenomenon is the Quebec Provincial Government issued an RFQ in end of 2008. And they specified IPv6 in there. In fact, Marc Blanchet, which some of you know, he’s the one wrote that part and in fact asked: Why did you put the stupid requirements in there. Quebec government just said: When we procure something, it has to be good for five years.

We’re certain and sure that we’ll run out of IPv4 addresses within this five years. So basically we want to avoid any bad surprises. And these bad surprises, they meant unbudgeted and unanticipated expenses. Because manufacturers and suppliers are a little bit cynical in their approach. They say, well, if the customer base is really pushed against the wall, they will pay a premium for the transition.

So I think if you specify today, I think it’s much better. And of course there are some suppliers ready.

And it’s all about survival in that global rat race. Thank you.

[Applause]

John Curran: Any questions? No. Thank you very much.

Pending ACSP Report

John Curran: Okay. Excellent. We actually have – next on the agenda it says open microphone, but we’re going to slip in one little presentation. We’re going to see if we can get this done in three minutes.

Come on up, Mark. From time to time we get suggestions that come in from the community on things we should do to ARIN Online and to our information systems. Mark’s the one who has to do all that. And he’s here to give a quick update on some of the things that have come in on the Consultation and Suggestion Program.

Mark Kosters: So while they’re getting the slide deck up, I figured I’ll start out with a story. And that story is when I was growing up I had a couple of sisters that were younger than me. But when it came time to doing things – you know, everybody does something and they get in trouble for it, but I always seemed to be the one that would get in trouble the worst. As I analyzed it I realized that my sisters always gave better excuses than I did. Right? And I found out how poor I was on excuses. So what I really wanted to do was rename this presentation: The Dog Ate My ACSPs.

No, that’s fine. So – but in reality that’s kind of a whimsical sort of statement. ARIN – when we receive these wonderful suggestions, we have to sort of forecast what – when are these things actually going to be placed. And as you know and we’ll be finding out tomorrow that we have really retooled our infrastructure and continue to do so. And so some of the forecasts that we have actually put out in some of these suggestions are – we have not forgotten about, but we will beginning to soon.

So let’s go do the first one. And that is the WHOIS service. I believe, Heather, that you put out the suggestion and it was submitted June of 2008. There’s the URL for it. And it’s answered in two phases. The first phase is upon request we’ll go ahead and do a WHOIS lookup for you and give you back the result. The second phase, according to the report, is that we would make this implementation available within WHOIS by the end of 2009.

Well, that obviously didn’t happen, because you don’t have that service. And you could go ahead and test to see if that’s really true, but I can assure you that it’s not.
So what are we doing about this? Well, we’re not going to update the legacy WHOIS service. Andy has given a presentation about WHOIS-RWS. It’s a much better finer-grained tool for you guys to use. But we’re not going to put it in there as well. And if we did it would be very expensive because there’s a lot of data that is placed historically within WHOIS. But we will make it a feature of ARIN Online in this report. This is something we’ll be putting into a process and figuring out where it actually is going to be scheduled and make that announcement known when we know ourselves where it’s going to happen.
The second one is a suggestion for a simple version of the IPv6 reassign template. So right now the reassign template for v6 is – it’s called a detailed reassign template, which means that you have to manage your organizations differently. And it’s really not very efficient. It’s not a great tool for v6.

Now, the v4 equivalents, there are two types of templates: There’s the detailed reassigned template for v4 and simple reassigned template for v4. For SWIPs, that we most commonly know as, it is the simple reassigned template that’s being used. We need to have the equivalent made for v6 as well.

It will be part of the RESTful provisioning service that we’re putting together. And that simple reassign template will be incorporated at that point. And this makes a lot of sense. This is something we’ll do. Again, we’re going to make this time known as we figure it out on the schedule.

The next one – how am I doing on time, John? Going fast enough?

John Curran: Faster.

Mark Kosters: Okay, faster. Okay. The next one is promoting the use of v6. We actually have had this available in ARIN Online in March of – March of last year, actually, where we have a little logo at the bottom and it says “v6 enabled.” So if your browser – if you’re on the v6 stack right now you can actually check this, and it has a little “v6 enabled” logo on the left-hand nav. That is available, but one of the things that it does not show, and I think David Farmer brought this up, it doesn’t have the v6 address on it.

John brought this up at the last meeting in Dearborn, that, hey, there are some framework limitations that we have that we’re working through. And we’re going to get through those. And one of the problems that we also have is there’s this Disability Act framework that we have to work within.

So we’re trying to work all these things out. The WCAG specifications that deal with disabilities are actually much more liberal and much less prescriptive on dealing with these things in the new standards. So I think we have a solution that we’re going to vet and make sure and we’ll be able to pump up your v6 address.

Next one. 2009.15. Speed up the timeline for POC validation. Well, you guys have already heard this. This came up yesterday morning, both with Leslie as well as I believe Andy talked about this as well some, that we will have this available at the end of Q2 of this year.

And the final next one is constructing validated IRR data. And what this is all about is really using – leveraging the RPKI system to actually sign and put things in within the IRR system.
Well, obviously we don’t have IRR deployed yet as a production system. We will by the end of this year. And we’ll be looking at incorporating this sometime at a point in the future perhaps next year. But, again, it’s something that we’re looking at doing in the future.

So, with that, I’m done.

John Curran: Questions. We have one. Heather.

Heather Schiller: So the first item was the WHOWAS and the interim measure was to be able to submit requests to helpdesk, and I wanted to comment that they will only – on the occasions that I have tried it, ARIN’s response has been the information you’re requesting about is in relation to a net block that doesn’t belong to you and so we’re not going to provide you that information.

And so I guess my question is sort of that is not what I had intended when I requested this service. And I’m wondering about when you provide this functionality through the new Web page stuff, are you going to limit it only to resources that you’re authoritative for in your account?

John Curran: Hmmm. hadn’t thought about that.

Mark Kosters: So there’s a bunch of AUP-like information that’s at the bottom of the actual suggestion in terms of the response that was given at that point. And I think those things need to be sort of fully vetted in how we go forward. We’re going to see some of this in ARIN Online. I’m not exactly sure what the answer is. I’m looking at some of the policy people, how we’re going to go forward. But I’m sure that’s definitely a vexing issue.

John Curran: Since that’s the purpose you want to put it towards, I think we need to go look to see if we can do it without violating anything that we have for agreement with anyone in the community. I’d love to say yes, but that’s really a legal review kind of item that I need to do.

Heather Schiller: I’m sure that when you – I remember you having the consultation portion, and I’m sure that I said that this was the intent; that it would be helpful for folks in the security community who haven’t been archiving this data for ages to be able to have access to run those types of queries to kind of track and monitor events.

John Curran: Understood.

Heather Schiller: I have another comment but it’s about a different item.

Owen DeLong: Owen DeLong, Hurricane Electric. I just checked the ARIN website both from v4 and v6, and it’s not a dancing turtle, but the IPv6 logo is cool, except it misses kind of the point, I think, of the suggestion, which is it does a great job of saying, yay, you’re on v6, but if you’re not on v6, it doesn’t do anything to say, yo, bub, get with the program.

John Curran: So your suggestion is just put the IP address or say –

Owen DeLong: My suggestion is if you come there via v4, have something there instead of the cool little IPv6 logo that says you need v6. You know? Maybe that’s a good use of gas mask dude.

John Curran: We were going to keep him just on the billboard, but I like that idea. So let me think about it. Okay. Back to Heather.

Heather Schiller: My other comment was about 2008-23.

Mark Kosters: Is that –

Heather Schiller: It’s the one about the simple SWIP template for v6.

Mark Kosters: Okay.

Heather Schiller: In San Antonio a year ago there were two sessions: one was the Web demo and the other was the future of SWIP. And in both of those there were a number of comments – I remember making the comment about, hey, it’s really great that you streamlined the v6 template into one template for all v6 SWIPs, and there were a bunch of folks who said, yeah, that’s great.

And it sounds like this item wasn’t opened for consultation to the community, but you’ve decided to go ahead and split it when maybe split it into a simple then detailed SWIP template and maybe – maybe that’s not the best thing. And part of why I say that is because I think that in some cases it’s helpful, particularly for some service providers to be able to go to their customer and say: Go to ARIN. Apply for an org ID. Give them whatever information you’re going to give them and just give me the org ID to SWIP to.

John Curran: Okay. Hold on. Can we get the slides up again?

Mark Kosters: To help this. This actually came up from a conversation from Aaron Hughes who is not in the room, I see. It’s not from Aaron? It is from Aaron, right? And he wants to do SWIP-like sort of reassignments on behalf of his customers, much like I imagine that most of you do as well.

It sounds like from what you’re saying is that you would want your customers to come in and apply for the Org IDs and go on or you would do that. Right now –

Heather Schiller: The detailed template requires you to provide an org ID. So what we’ve done is we’ve been telling customers go get your org ID, and then when you request space from us, list your org ID, we’ll check it, and then whatever. So I think what maybe Aaron was saying is kind of the opposite of what I’m saying. You know, you should have both available. And, yes, I know that having –

Really my point is: It would be nice if that were open to the consultation process to allow the community, give you feedback about how the process should be. That’s really the crux of what I want to say.

John Curran: Even if we don’t put it out for consultation, it’s still something that you can put in and say: Here’s my suggestion. I want it to work this way.

Heather Schiller: But it does work that way today. So would I put in a suggestion that says: Keep it that way; I don’t like that other suggestion that –

John Curran: Yes, you can do that. That’s fine. That’s good feedback. But I guess what you’re saying is that you don’t want us to make the change.

Heather Schiller: Yes. It sounds like you’re saying you’re planning to make the change. And as far as I know, that nothing in the notes for that suggest an updated – there was no like feedback saying that we’re going to – yes, we’re going to take this suggestion and do something about it. We’re going to implement this. But when you gave this presentation just now, you did say that. So there was no feedback to that.

John Curran: Got it.

Mark Kosters: Okay. Okay. I got it.

John Curran: So we will give you feedback on that and make sure it’s clear what we intend to do. And if you think that’s a problem, you can let us know. You can send us mail or send in a consultation process. Other comments? Yes, Nate.

Nate Davis: Nate Davis, ARIN. So just to follow up on this point that Heather made. So ARIN puts out these consultations from time to time from the community. And as Heather pointed out, nobody had really commented on that.

ARIN thought it was a good idea for us to pursue, so we were heading off in that direction. But it’s really important that when these consultations come out we are looking for community feedback so that we can know specifically what the community is looking for. So would really like to get that from everyone.

John Curran: If we get a suggestion and it doesn’t look to be a problem, it doesn’t take many people for us to incorporate it into our plan, if it’s relatively small. So if you see a suggestion, you really have to look at it to say: Do I like this? Do I object to this? And let us know, because we’re trying to be responsive to someone else in the community.

Heather Schiller: You only open the consultation – you choose when to open the consultation process. So, yeah, I could choose like discuss or PPML or somewhere to like start hacking up about these suggestions, but note that ARIN only opens a consultation process when they choose to do it about a particular suggestion.

John Curran: Right.

Heather Schiller: And they did not do it for Aaron’s suggestion. There was no consultation process about that. Which would be fine, but, I mean, there was no discussion about it. So you chose to implement it and there was no –

John Curran: I see. A suggestion that goes in isn’t visible if we just move to implementation; you don’t get a chance to get consulted on it.

Heather Schiller: Yeah. So it shows up on the Web page, but there’s nothing that goes to like PPML or anywhere else that says, hey, there was a suggestion; do you guys want to talk about it. And you only open the consultation process when – from what we’ve seen, you only open it when you’re specifically looking for feedback about some part of it.

John Curran: In truth, I guess what you’re saying is suggestions that come in should – you should be able to comment on as well when they’re opened. Shouldn’t have to be a separate consultation.

Heather Schiller: And the community, like there should be some process where ARIN notifies the community that a suggestion is – because I’ll go look at the Web page for it, but there’s no like teeing off –

John Curran: We were trying to keep it a fairly lightweight process, but I think I understand the problem here and I will dwell on it with the team. It should be possible to make sure you’re not injured by someone else’s suggestion.

Tom Zeller: It’s not every suggestion; it’s when ARIN decides to turn it into a proposal.

John Curran: The question is it’s when ARIN decides to turn it into a proposal. Some suggestions are pretty simple. If someone sends a suggestion in saying we need cookies in the morning at breakfast, not just at the breaks, okay, well, we look and we go, I mean, can we do that? Yeah, okay. And we see a suggestion. I guess it makes sense. We may put the cookies out without ever going to consultation.

So the question is when a suggestion comes in, we have to be aware that if anyone might want to comment we probably need to either let you folks comment on suggestions or always make a consultation. I don’t want to make it a heavyweight process because we do get suggestions as simple as “I hate that slide template; make it go away.” You don’t want to have to put that out to community consultation. So we’ll need to muddle on this one a little bit.

Max Tchepour: What happens if you hate that slide?

John Curran: Well – yeah, yeah.

Max Tchepour: Max Tchepour, Barrett Xplore. What happens if you hate the slide? Do you consult us to remove it or not? That’s the question.

John Curran: If we have anything that we think is significant, we try to put it out to consultation. The problem that we’re running into here is when a member of the community suggests something that we think is pretty simple but we don’t realize people are going to be – are going to see it as impacts. It’s not something we’re initiating; it’s something we’re responding to the community. And I guess the question is if it’s a risk of an impact, we probably need to engage the consultation process on it and let you find that.

Heather Schiller: To your point, ARIN has used the consultation process to reach out to the community when there was no matching suggestion. I guess last year they reached out about retiring e-mail templates. They had an open consultation with the mailing list and they also had presentations at the meetings. So they have done it in that direction.

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

[Applause]

Now is the time for the Open Microphone session. I ask the chairman of ARIN to come on up. Come on up, Paul. This session is available for anything you’d like to ask. I ask that you not take policy proposals that were on the docket since the AC is about to consider those and the discussion and the show of hands, but everything else is open table. Paul.

Open Microphone

Paul Vixie: Thank you, John. I regret not providing a basket of throwable objects next to every microphone so that I can get some people up there. It’s lonely at the podium when no one has questions. Make something up. Ah.

Scott Leibrand: Scott Leibrand, ARIN AC. We had some discussion with Raul, Jason, et al., about the global policy for the redistribution of IPv4 addresses. I would like to know either here or later if anyone in the community feels that that’s something that we should continue working on or not.

I’ve got some private estimations as to how likely that is to occur. But that really only matters if this community and the global community think it’s a good idea or not. So if people think that we should or shouldn’t, I’d like to hear about it.

Paul Vixie: John would like to speak to that.

John Curran: We have several CEOs of the RIRs in the room, and while we all may look like we’re typing on mail, we’re all actively paying attention to this.

So of course there has been immediately some discussion about the fact that, yes, indeed, the NRO NC did inform the executive committee of the NRO that this policy proposal was unlikely to gain consensus and that while we didn’t respond back then with direction, we probably need to pick up this item and give direction ASAP. I believe it’s been added to the agenda of an upcoming conference call, and that should provide some guidance on how to move forward.

Scott Leibrand: So that will be good guidance. If anybody in the community has guidance as well, I’d like to hear it now or later.

Paul Vixie: I likewise would like to hear it. My current understanding is that there is universal agreement that IANA ought to have a policy for handing out dregs or return space after run out and they’re looking to the RIR community to give them that and that there’s not necessarily universal guidance on exactly how IANA would get those dregs. So – rear microphone.

Martin Hannigan: Martin Hannigan, Akamai Technologies. Yes, I agree. I just want to reiterate the last comments I made at the last meeting where I suggested that perhaps a global transfer policy would be a better avenue to start with and that the weakness of the current transfer system is probably the bane of at least some parts of this policy.

Paul Vixie: Thank you. Same microphone.

Bill Darte: Bill Darte, ARIN AC. I share your interest in probably separating those two components as we’ve heard and offering that up. And if nobody else wants to write it or whatever, I will. But I’d be happy to have somebody contribute.

Paul Vixie: John would like to speak.

John Curran: I guess I need to clarify my comments. The guidance that I expect the NRO – the Executive Committee to give is how to dispose of the current set of policy proposals so we don’t have them hung up in each regional registry waiting for a global union that may never occur.

That won’t necessarily provide guidance on how to move forward with something that will get consensus, but it just tells us how to get rid of the dead proposals so we can make progress.

I don’t expect the guidance on how to move forward with something that might gain consensus really needs to come from the regions themselves.

Paul Vixie: Thank you, John. Center rear microphone.

Geoff Huston: Geoff Huston, APNIC. One of the coauthors of – I’m not sure if it’s a dead policy proposal or not, John, but I do want to understand just a little bit about the clarification or the amendment that was put through in this region.

My understanding, I suppose, to state it from what I understand of what was amended, was that it gave the ARIN secretariat really some degree of discretion around return of address space.

What happens is that when address space comes back, rather than it being a direct obligation to immediately send it back to IANA, there was some discretion. And it was my understanding that discretion rests with the staff as distinct from the community. Is that impression that I have accurate?

Paul Vixie: Go ahead, John.

John Curran: Absolutely accurate until such time as the community adopts a local policy that says whether or not the designated blocks are returned or not. In order to make the policy without having to force another policy to be written in parallel local, it was left as designate, but obviously the staff will follow whatever this community does. Our practice has been that organizations that want to return address blocks of substantial size – example, /8 – have been in the past directed to work with the IANA to get those returned to the IANA.

So at present I’ll follow that practice until this community says otherwise. We don’t have a formal policy. We’d almost certainly need one if this global policy were to go through.

Geoff Huston: I think I said it almost precisely a year ago in San Antonio. But I do think that as we approach exhaustion, the queue of “I told you so’s” and folk wanting to drive wedges within our community to demonstrate that the RIR system is inherently flawed and weak, the queue will be long.

And I certainly see that folk will be picking over the history of some of these attempts to coordinate ourselves globally and act as much as we can with one purpose, with regional voices, as being important for us. And I would certainly like to see us work towards making this particular demonstration that we can work together come to fruition rather than see it founder on possible misunderstanding and to some degree slight difference. So it’s my hope we can indeed get something out of this.

John Curran: I think that would be wonderful.

Geoff Huston: Thank you.

Paul Vixie: Thank you, Geoff. At the right.

Joe Maimon: Joe Maimon, CHL. This is just a quick jump back to the static key issue you brought up before. And the fix, which was to not resolve anything, just to clarify, the annual rollover to KSK won’t trigger any of these issues either, will it?

Paul Vixie: It should not trigger any of those issues.

Joe Maimon: Thank you.

Paul Vixie: Same microphone.

Raúl Echeberría: Thank you. In part, most of the comments I planned to make were already made by Geoff. So what I can say is that as an author of the proposal that is known in the ARIN community as 2009-3 is I commit my efforts to work with the other authors to get the proposal that could be acceptable for all the communities but at the same time used for the positive. Because if we get something that get agreement in all the regions but it’s not useful, then it doesn’t make sense.

One question for John. John, do you think that the proposal should also formalize the fact that the /8s when are recovered by one RIR has to be returned to IANA?

John Curran: That’s a policy matter that I would give to this room to answer. I’ll note that when ARIN adopted its version of the global policy, it was noted that ARIN still, right up to exhaustion and beyond, has a documented need-based allocation system. And that’s not consistent among the regions.

So if in some regions you don’t need to have documented need to move addresses and in others you do and addresses are returned to the IANA, well, it’s sort of the bucket acts funny if there’s a hole in it on one side. So that might need to be looked into. But it’s truly up to this community.

Raúl Echeberría: I will reformulate my question. As there is an agreement in place among the RIRs that was even communicated to IANA some years ago that when IANA asked what should be done when – if a /8 could be returned to one RIR, so we agree that we answer to IANA that if a /8, entire /8 could be returned to a given RIR, so that /8 should be passed to IANA for further allocations.

So my question is: You feel that it is not enough solid basis for doing that? This agreement is not enough for an RIR in that case – in this case, for ARIN – to proceed with that return?

John Curran: That’s been the practice within ARIN. That’s the historic practice, correct. There’s no policy that documents that, but until this community says something else, I would follow the existing practice. So this includes /8s that were returned in, for example, 2007, three /8s. We were approached by organizations within the ARIN region to return those, we directed them to the IANA, and now they’re in the free address pool soon to come back out the other side as soon as we need them.

Raúl Echeberría: Thank you very much.

Paul Vixie: Heather would like to be next.

Heather Schiller: Can we bring up the questions that we didn’t finish yesterday? We did the first one – sorry. I thought it was still on. So these were the questions we were discussing yesterday when we were talking about 2010-5. We talked about the first one and I wanted the opportunity to discuss the last couple, if anyone has any…

Chris Morrow: I just wanted to mention a few things about the renumbering. There were comments at the mic about renumbering for some ISPs is hard and such. I think that the – awesome. Somebody else is going to speak about this.

I think the renumbering thing is hard, depending on what your environment looks like. So Web hosting folks, it’s probably a lot harder for them to renumber than sort of pure consumer ISP where DHCP rules. Also, sort of the time period sort of plays into it. I think the renumbering thing is difficult to do today. It’s going to be difficult in v6 as well. So we should think really hard if we’re going to make a requirement that we renumber out of space. And maybe only you renumber out of the small block. After that you sort of – you win, right?

Heather Schiller: So that’s what the policy attempted to do, right? If you were under a /22 or something, you were to renumber, and I think a lot of folks still got up and said renumbering is hard. So where is that threshold? At what point do we say –

Chris Morrow: I think the guy at the mic was somebody in the back corner over there yesterday, said something about renumbering three times, sort of like renumbering out of provider space and independent space, then run out of independent space to the next independent space, and then some other renumbering he mentioned as well, which maybe I’m confused about that. But I’m not sure what the threshold should be.

But it becomes hard to renumber a large network, even if large is a 22 or a 20 of space, right? If you have customers that have static addresses, it’s nearly impossible to renumber them.

Paul Vixie: Before we go to Owen, I want to point out one of the most compelling observations that I have seen around the renumbering question is that if you are a provider and maybe you have some downstreams and maybe some indirect downstreams, renumbering for you may mean renumbering for a lot of other people. And if they have to renumber, that was most of the penalty of what would have stopped them for shopping for a replacement ISP. So to the extent that we’re asking some part of the provider community to bear a disproportionate burden of renumbering their customers, we’re also asking them to bear a disproportionate burden of losing those customers to competitors at those times. That may not be in the community’s best interests. Owen.

Owen DeLong: Owen DeLong, Hurricane Electric. Paul just did a very good job of saying a lot of what I was going to say. But the difficulty of renumbering has nothing to do with the size of your address block, or at least very, very little.

In my experience, having done a few renumbering projects in my days, the difficulty of renumbering comes from the number of places where your addresses appear in configuration files that you do not control. And as an Internet Service Provider, this is generally a larger number and has at least two levels of depth to it than as an enterprise, in my experience.

As an enterprise, it still is potentially a large issue. For example, some enterprises have a lot of partners, a lot of suppliers and/or a lot of clients that they have VPN connections to that involve firewall filters that are configured by one group at their client supplier or partner. VPN terminations that are configured by another group in their client partner or supplier, et cetera, et cetera, and so renumbering a single /29, if it contains five VPN terminators, each of which terminates 100 VPNs, can be a much bigger project than renumbering a /22 full of DHCP clients.

It really can vary a lot. And so I think that any requirement of renumbering on an ISP is onerous, and most requirements of renumbering on an enterprise below / – I’m sorry, with a shorter prefix than /22 are definitely onerous. /22 and larger I think there’s a lot of tradeoffs, but I think that’s probably where the community is going to possibly achieve some level of consensus.

Paul Vixie: Thank you, Owen. I want to caution. Nobody forgot what you said yesterday when you said most of the same thing. So thank you for reminding us. But let’s get on with the discussions. I renumbered an enterprise in 1989. It was Digital Equipment Corporation. We had five /16s globally. Three of them were absolutely jammed full. And it was the worst 72 hours of my life and the company was down hard. Fortunately, the IP network wasn’t a big deal in 1989 the way it would be now. We were excited to get net16, but it wasn’t easier because we were in an enterprise. Global enterprise can have a hell of a time renumbering. Left microphone.

Chris Grundemann: Chris Grundemann. Now I’ve lost my train of thought. So I guess the first thing I wanted to say when Ted and I were crafting the policy that these questions are based on, right with this combination of things, the thought process was that these are ISPs that wouldn’t be able to get addresses today, and so adding a renumbering requirement to be able to get space at all.

It was kind of the idea that if you’re an ISP that right now you’re in a position where you cannot get ISP addresses, this policy would allow you to get ISP addresses – to get provider independent space, to get PI space. But the idea is you only would do it when you only absolutely needed to. If you were in a situation where you felt you needed to get PI space, the PI space wasn’t working, and so it’s unlikely that you would need to come back for a second one. And if you did, you’d have to think about it and do the renumbering.

That being said, I’m personally not against having a policy that lowers the threshold and collapses the multi-homed and non-multi-homed without multiple renumberings. But when that idea was floated initially, there was as fierce of opposition to not – to giving out those addresses and having table bloat as there is this week to making them renumber.

So I’d kind of like to get a feel, if anyone would speak to it that is against the renumbering, that if there’s maybe – you know, instead of renumbering potentially four times up to a /20, if there was one or two renumberings or if there’s a threshold that’s acceptable or if it’s just no renumbering other than the first renumbering. Also, if there were a proposal to lower the threshold without renumbering, are there people who are opposed to that? If there is anybody who feels strongly about that, I’d like to hear about that.

Paul Vixie: Thank you, Chris. To the extent you have interest in these clarifying questions or the things that are coming up, like the questions Chris just posed, please get in the queue. We have a few minutes here. Center and then right.

Dan Alexander: Dan Alexander, ARIN AC. Slightly touches on that point. But for us to write a renumbering requirement into policy, if that is the case and I get my second allocation and I say no, it’s been really difficult, I have one problem customer and I haven’t gotten around to renumbering and I can’t do it, what does ARIN do?

John Curran: The question for staff is: You’ve agreed to renumber?

Dan Alexander: Well, it’s in policy.

John Curran: In this policy it says in order to get your next block you have to renumber.

Dan Alexander: Actually, it doesn’t. It says you can have your second allocation and you have to renumber out of the first.

John Curran: Right. So you have to renumber in return, much like our amnesty policy. We tell you have a certain amount of time. We give you the new block. You start renumbering. The timer expires. There are timers. One of us calls you up. You inevitably say, Well, I’m almost there but I’ve got this other little thing and the dog ate my homework and, you know – and we go, Okay, so how long? And we reset the timer. We do that a few times.

Recognize that we have the ability to pull that block you’re renumbering out of, put it in the list of blocks that have been pulled and reissue it. So you’re kind of at risk. Generally we don’t do that without a cooperative dialogue. But if someone’s actually saying, I’m kind of done with my project and I’m not renumbering, sooner or later that’s not going to get routed because sooner or later it’s going to be assigned to someone else.

Dan Alexander: To that point, that’s why, from what Chris was saying earlier, my personal opinion is I would be much more in favor of just a straight lowering of the thresholds without any kind of renumbering requirement, because we’re going to be coming into a situation here where that situation may be quite numerous.

So now you have ARIN staff managing transfers under Section 8, Waiting Lists, people blacklisted because they haven’t renumbered. All of this is just going to pile up into such a complicated mess. Just simply lowering it without a numbering – renumbering requirement would make things much easier to manage where we’re going.

John Curran: So just – I concur with you. It would be simpler to manage without a numbering requirement. I don’t know if that’s good or bad, but it would be simpler and easier on staff.

Paul Vixie: Heather has asked for the clarifying questions. We don’t need answers right now. She’s trying to get the community.

So we’re ten minutes after the hour. I’d like to close the microphones soon. If you’re not in queue and you wanted to get there, please get there. Right-hand microphone.

Joe Maimon: Joe Maimon, CHL. I just wanted to look at the other side of things. There are good things about renumbering. For one, it kind of teaches you address abstraction. The next time around it’s better. If we kind of eliminate all renumbering, then things aren’t going to ever get any better. In fact, they’ll backslide. They’ll get worse. In which case maybe we’ll need a policy that does sort of a random renumbering every two months, we pick somebody, we say “you renumber.” That’s all for now.

Paul Vixie: So I’m going to close the queues. If you’re not in the queue now, then give up. Center microphone.

Michael Richardson: Michael Richardson, Sandelman Software Works. My feeling about the relaxing – I guess this is the policy that moved from /22 to /23, I think is the minimum requirement, whether that’s requiring renumbering.

I guess my feeling is that if we can somehow structure it such that previously if you had gotten a /22, you might renumber into a 21, and then you might renumber into a /20, right, and then that would be it for you. Next time you asked for address space, you might get another /20. So it’s two renumbers.

So if you change it to /23, that’s great. So the question is maybe can we structure it such that maybe when you go from a /23 to asking for that /22, you don’t have to give up the /23 maybe, but when you go from the /22 to the /21 or the /20, then you’ve got to give it all back. So it’s still two renumbers, I think. Okay. But you get basically a lot – you could almost implement this is a lot longer grace period on that first /23, how long you had to get out of it.

Because likely for the new minimum initial allocation of /23, we’re talking about, let’s say, relatively inexperienced ISPs that don’t have much going on and they’re not going to know all the risks and that stuff. So we could be a little bit more tolerant that way, I think. And I think that would make it acceptable. Because it’s really not any worse than it is now. But we still get to give out smaller pieces and therefore give it to more people. Thanks.

Paul Vixie: Thank you. I want to point out that in practical terms, some of the sticks and hammers that John was describing as far as trying to get people to complete their renumbering amount to a two-renumbering policy, because if you outgrow a /22 and so you get a /21 with promise to renumber and then you outgrow the /21, you’re absolutely not going to get your /20 until you have completed the renumbering that you promised that got you the /21. So there is kind of a similar effect to the last proposal, just as an implicit side effect of the way the current proposal or the current policy is enforced.

So, Jason, you’re going to be the last. I’d like to know, Heather, are we answering these clarifying questions to your satisfaction?

Heather Schiller: Yes. I’d like to hear a little bit more about the kind of enforcement of renumbering and how realistic people think it will be in depletion. But I kind of have an idea myself.

Paul Vixie: I’m going to give John the last word on that topic, but let’s first hear from Jason.

Jason Schiller: Jason Schiller, Verizon, UUNET and the NRO NC. I think Raul asked a very important question, which was: Given a global policy to allow IANA to continue to allocate addresses after the exhaustion phase, and if they have smaller chunks, is it essential that such a policy include a requirement to return reclaimed addresses back to IANA.

And that question was asked of you, John. And I believe the answer that I heard was – in addition to some description about what we’ve done in the past, the answer was it really lies with the community. And I was expecting that that question would get redirected back to the community so that we could get their input on the topic seeing as we have them before us right now.

Paul Vixie: So we are 16 minutes past the hour and the community is going to start needing to go to dinner soon. So this may not be the best time to open our controversial thing with long queues at the microphone. Nevertheless, let’s do what we can with the people while they’re still in the room.

John Curran: So the problem is the question, is a question, that while you want to send to the community, you want to send it to the community as part of a policy proposal. Because there are parties that would want to comment on that that did not see it on the agenda and does not know what’s being discussed. It’s literally improper to try to get the sense of the community when no one’s been told that’s going to be discussed at 5:17 in this Open Mic session.

So to answer your question, what ARIN staff would do right now is we have no choice but to turn around. We would ask – as has happened in the past, I can say – we would all certainly confer with the board if one were to come back on what to do. But we have no policy. If the community wants a policy on what should be done there, I think that’s a great use of the policy process. Until such time, it would be the discretion of staff. We would, because of the importance of this, almost certainly check with the Board, but we’re relying entirely on existing practice.

Jason Schiller: Thank you, John.

Paul Vixie: The queues were closed, but because your beard is gray, we’re allowing it.

Scott Bradner: I didn’t think that was the question – that was an answer to the question that was asked. The question that was asked, I thought, was: Does there need to be a linkage between a policy saying IANA can hand out chunks and how the return has to be done.

Paul Vixie: That is certainly a different question. Jason, is that what you meant to ask?

Jason Schiller: That’s what I meant to ask.

Paul Vixie: John, please try again.

John Curran: If that’s the question, then –

Unidentified Speaker: Can you restate the question?

John Curran: Scott’s already sat down. Okay. Is the question: Does there need to be any linkage between the policy for return of address space and the policy for how IANA issues address space?

Jason Schiller: Jason Schiller. So I really think it’s Raul’s question and we should ask him for that. But I believe that was what he was trying to ask, and I believe that was what I was trying to also ask.

Paul Vixie: We have a Ping-Pong ball.

John Curran: Why don’t you ask it for him just to make sure, since you – that’s what you were trying to ask.

Jason Schiller: I tried to do that, and apparently I failed.

John Curran: Okay. One more time, just so we all understand.

Scott Bradner: Does there have to be a linkage between giving IANA the authority to hand out chunks smaller than a /8 and a mechanism for returning addresses to the IANA?

John Curran: No, there does not have to be any linkage. I see Geoff with his mouth open.

Geoff Huston: The community question – the thought process that led to this proposal being presented is a global policy proposal. Certainly anticipated scenarios where blocks smaller than a /8 would be coming back potentially. And the idea expressed in the policy was to send that back to IANA and distribute it again in units smaller than an /8, so the two were linked for that reason.

So it wasn’t just, oh, you keep everything until you get an 8 and then you hand it back to IANA. No. The intent in terms of what was there was that we’d like to be able to use that redistribution for smaller blocks, and to do so we also had to adjust the IANA policy.

So that’s the motivation. Whether that answers your question or not, I won’t have a clue. But that was the motivation in terms of why the policy was drafted the way it was.

Paul Vixie: So I’d like to clarify that the lack of linkage that I heard in John’s response has to do with current policy and current mechanisms by which ARIN staff would decide what to do if this community were to advance a policy proposal that linked them, they would be linked. If this community advanced a policy proposal that did not link them they would not be linked.

I understand that Geoff and other authors of the current global policy had certain goals in mind and that those are linked. And in which case Raul’s question was for Geoff rather than Jason’s question being for John. I believe I have the Ping-Pong balls back in the pockets now. I’d like to return to Heather and say is there anything more you’d like to – no.

The queues are closed. That completes the Open Mic session. Thank you.

[Applause]

Closing Announcements and Adjournment

John Curran: Okay. I’d like to do a couple quick announcements. We’re at the end of the day and adjournment. Here come my announcements. You have an opportunity to fill out a survey. We tend to run late, so today you have 37 minutes to fill out your surveys. Please fill them out and you’ll be entered in tomorrow’s drawing.

Sponsors. I’d like to have a big round of applause for TELUS.

Reminders. We’re going to meet tomorrow 8:00 a.m. Breakfast, 8:00 a.m. Meeting, 9:00 a.m. It is – there’s no policy proposals; it’s our member meeting. Agenda is in your meeting folder.

Tonight there’s a social, social on the Trading Floor, sponsored by the Toronto Internet Exchange, FONEX, Hurricane, Telnet, BTI. It’s going to be a fun event. Walking distance from the hotel. It’s 7:00 p.m. tonight. So you just need to sort of walk around the corner to get there. The folks at TorIX are putting together a wonderful time with lots of things. There will be a poker tournament and there will be food and drink. I think – I don’t have a slide on it. So that’s it. People should know there’s more information in your package. But it’s at 7:00, three blocks away. I hope everyone can make it tonight. And I thank TorIX for arranging this. They’re actually out there doing the logistics as we speak.

That’s it. I look forward to seeing everyone tomorrow. Thank you.

[Meeting concluded at 5:23 p.m.]

Network Sponsor

Info Center Sponsor