ARIN XXVII Public Policy Meeting Draft Transcript - 12 April 2011 [Archived]

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

Opening and Announcements

John Curran: We’re going to get started. Glad everyone is here. First, I want to invite up my good friend Juan from AT&T. He actually worked for me once in the dawn of time. He’s our network sponsor.

And he has a few words for everyone. Thanks. Come on up, Juan.

Juan Medero: Thank you, John. You’re right, it’s been a while since we worked together, but it was a wonderful time. Right at the start of everything.

So, first of all, welcome to Puerto Rico. I hope you’ve had a nice day, and you continue to do so.

The weather is really nice, and I know it’s hard being here doing all this hard work, when the weather’s out there.

But the more that we appreciate you being here and doing the important work that ARIN does, regarding the establishment of the policies, we’re right in the middle of a lot of the work and the policies that need to be in place to make the Internet work, especially through all this transition.

So I just wanted to briefly welcome you, appreciate your stay on the island. Make sure you have time to go and visit the different points, museums, art galleries. Old San Juan is a very beautiful location.

The network, it’s available. Any issues regarding both wired and wireless, as well, just let me know. And we’ll be very happy to help.

So with that, you know, I welcome you again. And have an excellent stay. Thank you.

(Applause.)

John Curran: Thank you very much. I hope everyone enjoyed last night’s social, and I want to give a round of thanks to our social sponsor dot PR.

Okay. So, remember, the question of the day, if you want to be recorded answering this question: How would you describe an ARIN meeting to someone who has never attended.

We’re going to record a couple of snippets from people and use this in the video that we use in our trade show booth and to inform people about what the nature of an ARIN meeting is.

Find people outside from Member Services at the break if you want to be involved.

Rules and reminders. The Chair will moderate discussions of Draft Policy so everyone can speak and be heard. Please state your name and affiliation each time you’re recognized at the microphone.

If you’re in favor or opposed of the Policy Proposal being discussed, please say that. Please comply with the rules and courtesies outlined in your program.

Today’s agenda. We have a few reports. The IANA Report, IPv6 IETF Activities report. We have updates from the regional registries.

We’re going to talk about new features in ARIN Online and we have resource certification update and we have the PDP committee report.

In addition to that, as always, we have an open microphone. We also have discussions of policies. Today’s policies that we’re going to discuss, 2011-3, Better IPv6 Allocations for ISPs.

We’re also going to discuss Draft Policy 2011-5, Shared Transition Space for IPv4 Address Extension.

So it’s going to be a busy day. As always, we welcome remote participants. We’ll make sure that we make time for your questions, make time to see you in the show of hands when we do a show of support.

At this point I’m going to make sure that we get going. At the head table we have Scott, we have Heather, we have Marc, we have Bill, Paul, and our chairman, Mr. Denton.

So let’s get started first presentation will be the IANA Report with Elise Gerich.

IANA Report

Elise Gerich: Can you hear me? Oh, good. Good morning. Thank you very much. I’m Elise Gerich. I’m from ICANN, the IANA. And I am really happy to be here.

As you can tell it’s so much fun in Puerto Rico. I think I’ve lost my voice. So hopefully I’ll be understandable.

This is I think the first time on an IANA Report I’m not going to talk about numbers at all. There’s been enough talk about numbers yesterday, and my pockets are empty. I don’t have any more IPv4 in my pockets.

So it’s not premature to talk about IPv6, but you all have plenty, and I think there’s no reason for me to belabor that point.

So today what I will talk about is a little bit about DNSSEC, very little, about root zone management automation. It’s a project that’s been ongoing at the ICANN and IANA department. The Notice of Inquiry that was put out recently about the IANA functions by the Department of Commerce. And then I’ll talk about Business Excellence, which is a program that’s been ongoing at ICANN for two years.

So what about DNSSEC? Well, in the reverse zones and DNSSEC, there’s been an activity between the RIRs and particularly ARIN and ICANN in order to transition the management of the IN-ADDR.ARPA zone and the publication of that that ARIN has taken over since 1997.

And this is an activity that we’ve been working on, and so we’ve been transitioning that. And also then getting the IN-ADDR.ARPA and all of its child zones signed in the root.

This has been accomplished, much thanks to ARIN and the other RIRs, and it’s now transitioned to its new state.

So basically there’s a bunch of new nameservers for IN-ADDR.ARPA. Previously the nameservers were managed by the root server operators. Now these nameservers are managed by the RIRs and ICANN.

And so if you go out and query for them, you’ll find them out there. I did forget to say that this is consistent with RFC 5855.

It’s been a while in coming, and I want to thank John for reaching out to – that’s John Curran to my left here – reaching outing out to ICANN so we could facilitate this transition.

And so the IN-ADDR.ARPA zone, the edit function has moved from ARIN to ICANN. And it moved the root of, like I said, the DNS root servers and was signed in February.

So if you want any information, there’s a whole project plan and the steps that transpired at this URL that’s up on the screen.

So thank you for your cooperation, and I think nobody even noticed as I can tell. I didn’t get any complaints. So it’s one of those things that happened in the background.

Oh, as for IPv6 ARPA, it was moved earlier in December and it was also signed in April of last year.

So root zone automation. What does that mean? So I don’t really know what my predecessors at ICANN and IANA spoke about in the past about this, but I hear it’s had a long and tortuous process; that we’ve been working with NTIA and VeriSign for a number of years to automate the process of handling the transactions for change requests.

Those are contact change requests, delegation, redelegation requests, nameserver requests, other kinds of requests that come to IANA for changes.

So this is about to go live. We’re in parallel testing right now with VeriSign and NTIA, so that what that means is that we have a production network where we still do everything manually.

And then we have a parallel system setup for the root zone automation. And when we get a request, right now we enter it both manually and we enter it into the parallel system, the automated system.

And we’re checking that, and it has to run 100 percent clean for 60 days. And if it does that 100 percent without any glitches or wrong output, we’ll then have a plan to transition.

So we’ll be communicating with the folks who run TLDs and letting them know that they’ll have their own user account to submit the information directly when they want to into the automated system, and there’s a process flow that will go all the way from the beginning to the end and you’ll be able to check it with trouble ticket numbers.

So we’re in the 60-day window now. Our expectation, if all goes well, and there’s no glitches, is that the root zone automation system will be live in July of this year, 2011.

So a lot of you are aware of the Notice of Inquiry that the Department of Commerce posted for the IANA functions.

ICANN’s contract with the Department of Commerce for the IANA function expires this September, September 2011. And I know many people in this room have submitted comments, because I’ve talked to some of you and I know you, as well as the RIRs through the NRO. We thank you all for participating in this process, because it really does give welcomed feedback and input on what the community at large would like to see happening with the IANA functions.

So there were more than 70 comments sent into NTIA. They are posted on the NTIA website, and I’ve put that URL up there for you all if you’d like to go out and read. It’s good bedtime reading if you really have insomnia or something.

So, finally, my last topic is about Business Excellence. So prior to my joining ICANN, the IANA department had started a Business Excellence initiative, which is based on EFQM, which is the European Foundation for Quality initiative. And this is actually an initiative where you look at who your stakeholders are, what your processes are, what your metrics are, how you measure yourself, and how you interface with other departments within your organization.

So we’ve had typically a whole company or corporation would do this. We’ve only been focused on the IANA department itself. And so this last year what we did was we focused on processes and reviewing what processes were documented and not documented, and having an initiative to really document and come up with a model that was a consistent model for documentation of our processes.

So we have a process model and we’ve completed the documentation of over 14 of the processes which have to do with the transactions that we manage for the community.

So our initiative for this year, with the business excellence program, is to go through those business processes and say, okay, what are the key performance indicators to show that we’re succeeding and that we’re meeting and we’re consistently applying those processes to what we do.

And so that’s something that we’re actively engaged in. In fact, Leo Vegoda, who usually is here to speak with you, isn’t here because he’s back home. They have a couple of workshops this week where they’re looking at what the key performance indicators should be for some of the processes that we’re working on.

I think we’re quite pleased with the self-assessments that we’ve done each year at the end of a Business Excellence cycle. You have a self-assessment, and it’s done following the EFQM model, which is quite well defined and there are different categories. And it’s kind of like playing that card game, poker game Indian, you know where you put a card up on your head and everybody has to guess who has the highest card.

So with the EFQM process, you have a ranking system and an ordering system. And you have at least up to eight evaluators internal self-assessors, and you have very fixed criteria, and you have ranges of how you can grade that criteria, and then as soon as each person has chosen their grade you hold up your card and you look around real quickly.

And if there’s a spread of more than 20 grading points between the highest and the lowest, you have to defend what your grades were, and then everybody puts their cards away and you hold up a new card until you don’t have such a huge gap.

So it’s been a very interesting learning experience, and I think we’ve become better at grading ourselves and being a little more constructively critical.

So with that, I want to thank you very much for your time and attention. And I’ll let you get back to your normal agenda.

Oh, I guess there are questions.

John Curran: Questions?

Vint Cerf: Vint Cerf, Google, and member of the Board. Just a question, Elise, with regard to the root zone management. What kind of authentication is used to validate the TLD operator when using that system?

Elise Gerich: You know, I’ll have to get back to you on that. I don’t know the details.

Vint Cerf: The purpose of the question is to ensure that there is as strong as reasonable authentication. I would push for two factors, if possible. But at least some cryptographic element.

Elise Gerich: Right. I’m sorry, I just don’t have the detail of that implementation, but I’ll find out.

Are there any other questions?

John Curran: Any other questions for Elise?

Elise Gerich: Thank you all very much.

(Applause.)

John Curran: Okay. We’re going to move next into the IPv6 IBA/IETF Activities Report with Cathy Aronson.

IPv6 IAB/IETF Activities Report

Cathy Aronson: Hi. This is a new thing for me. So, anyway, I’m going to give a report. I went to the IETF like a week ago, I guess, I’m still jet-lagged, in Prague. Here we go.

This is a standard disclaimer. There’s no official liaison, everything you’re going to see is my opinion, whether you like it or not.

Anyway, something else, I collect quotes, so anytime you say anything around me, remember that it might end up in my presentation. And if you have any comments or thoughts or if you were at IETF and I got something wrong, feel free to let me know.

So for those of you who didn’t know, I used to go to IETF a really long time ago. And at 10 years exactly, and I found the first thing I found when I got there was that people are a lot grayer than they used to be. And that people would start talking to me and I only knew them because their voice was the same as it was 10 years ago.

So that was pretty exciting. Something new happened. Something exciting. RFC 6177 got passed, and that’s the new recommendations for v6 for end sites.

So if you haven’t read that, it was a lot of work by a lot of people. And it’s pretty exciting. This is the first quote that was exciting at the meeting.

I guess the text is big enough that you can read it. X.400 was a mail protocol under OSI which was the predecessor to IPv6. It went from the technology of the future to the technology of the past without ever becoming the technology of the present.

And if you guys – I mean, this is – there’s a fellow that gave a talk in one of the working groups I went to, and it’s really pretty interesting about some pathologies. So, anyway, it’s not really part of any particular working group. But if you’re interested in it, it’s pretty interesting about the pathologies of buffers on the network, it’s pretty cool.

Anyway, so just the first thing I want to talk about was not actually part of the IETF but there was an ISOC IPv6 workshop. Lee Howard was on the panel and a couple of other people.

They were talking about like how do we know when we’re there, how do we know when v6 has arrived or whatever.

And so some of the take-aways from that, some of the topics were wait until v4 is finally on the verge of collapse or maybe we run out of address space. And finally people realize that they need to move quicker.

There’s still problems with carrier grade NATs. There’s a big problem that little guys can’t get transit from big guys. And then cable modem support, the home gateway support, I guess, isn’t really there. So 99 percent – you can deploy it on your network, but if your customers can’t actually access it, that’s a problem.

How do you really measure it? So one of the things – some of the statistics that were presented are here. RIPE has a really interesting thing they do. It’s called IPv6 RIPEness. Catchy, huh?

They actually do some measurements of like who has what in the DNS and it’s not actually connectivity, but they give you like four stars if you have all four of them.

And they’re looking at putting – I think it was on the previous slide. They’re looking at putting a route[6] object of a pingable address so you can verify they have connectivity.

If you have all the criteria, then you get a T-shirt. Pretty exciting. Anyway, it was an interesting discussion.

And I think that maybe we should start discussing like how do we know whether we’re there or not.

Anyway, so to go on to some of the other working groups. The Internet area is working on an RFC to define, to change the definition of what has to go into an IP implementation.

So they’re starting to say that it must not require v4 and that it must require v6, which is a really big step that finally they’ve decided that you have to implement v6 and that the v4 and v6 implementations must be equivalent. So your v6 can’t be any less functional than your v4.

And then there’s some other topics. I’m not going to go into every single bullet, because I only have 15 minutes.

Wesley George: Wes George, Sprint. As one of the authors of the draft that is saying must support IPv6, one of the things that I would recommend is if you are nodding in agreement or saying, wow, this is way overdue, I would encourage you to start monitoring the area working group mailing list.

And when this comes up for working group last call in a few weeks, hopefully, please voice your support on the list.

IETF is a consensus-driven organization. We ran into a few folks that were sort of unsure of the usefulness of this draft in terms of actually making real impact on the situation.

And I think all the support that we can get I think will be helpful in kind of reiterating to the IETF that we think this is important.

Cathy Aronson: Great. That’s a really good point.

There’s a renumbering RFC that was written a really long time ago. It’s not really clear that anybody ever actually used it.

But there was a BoF to talk about renumbering networks, how to document how to renumber networks, because even with v6 there’s a belief that you’re still going to want to renumber your network.

It was an interesting discussion and a lot of negativity from most of the people that would have to renumber networks about how hard it would be to actually document that.

So if you’re interested, they’re probably going to form a working group.

Geoff Huston, who is here somewhere, gave a really great presentation at the v6ops working group about the pathologies that currently exist in v6. Some of them are listed here.

And he talked about how auto-tunneling sucks less than you think and that there are badness clumps. I love those quotes. But sounds like there’s a lot of work left to be done to fix some of these things. So you should check out his slides. I don’t have the URL. I couldn’t actually find it. But it’s at teredo.net, I think. And the IETF proceedings will have it.

There’s some things going on in the routing area working group. And on all of these I put if you want to go and look there’s endless numbers of documents in all of these working groups, there’s a link in each one of these slides that has where you can go to get them. I wasn’t going to list them, because it’s crazy.

SIDR working group has made a lot of progress securing BGP. I think one of the big take-aways is as you go through your cycle, your five-year or seven-year cycle to upgrade your border routers, you should think about sizing them to be able to do BGP security, because it’s going to require more processing and various things for your router so as you go through that process start thinking about that and asking around.

Let’s see. Yeah, v6 man, there’s a lot of different things. I like this quote: “I never thought we’d ever have almost no deployment of v6 and someone saying that we can’t do something in the non-existent deployed base.” That’s pretty awesome.

There’s a whole lot of extensions and node requirements, RFCs, they’re working on what should be useful to participate in if you’re interested. And somebody coming to the microphone? No.

Just checking. The benchmarking methodology working group, which Scott Bradner started about a million years ago is near and dear to my heart.

And they do stuff so that you can repetitively test equipment from different vendors for the same, compare apples to apples.

And they have – they’re working on this thing called Happy Eyeballs which will let you see whether dual stack hosts make the users happy and they perform like they supposed to.

Like Lee said, DNSSEC is here. It’s pretty exciting. They’re working on some trust anchor documents and operational practices.

Let’s see. I’m going to not talk too much about this one. BEHAVE. If you’re into NAT, BEHAVE, that’s all they talk about. Every possible kind of NAT. v4 and v6. And v6 and v4. And there’s a whole lot of analysis going on of the different forms of NAT. And deprecating old ones.

I think I missed something I was going to talk about. But here are the various places, the Daily Dose page is really nice. It gives you a whole overview of who is doing what and what drafts are in what state and all that sort of stuff.

John Curran: Okay. Any questions for Cathy on the IETF update? Microphones are open.

Alain Durand: I chair two of the working groups that you didn’t reference here, the Softwire and the PCP working group. And I wanted to give a brief update on those two.

In Softwire we – in IETF last call on the dual stack light technology, so this one should go as an RFC, Unix and Linux. And PCP is a new working group we just created in September last year to enable application to talk directly to the NAT and to open a port and that’s both in IPv4 and IPv6, and the work has been doing is with a lot of meetings on WebEx and a lot of energy behind it and we are planning to start a working group last call on this in the next week or so.

Bill Woodcock: I have one of those synergistic questions that ties together the crazy working group on NAT and Elise’s talk about how we finally got DNSSEC signatures over the IN-ADDR.

So 4to6 NAT breaking DNSSEC signatures, IETF working on this? What’s going on? This is something that we’re all going to have to deal with at some point. Either of you guys –

Cathy Aronson: I don’t know. Sorry.

Alain Durand: If you’re talking about DNS 64 and NAT 64 in particular that could break DNSSEC, the way to check that is that you have signature verification between essentially the DNS 64 slot and the originator, and then you have a different trust relationship maybe using TSIG or whatever you want in between the leaf node and the DNS resolver. It’s broken up in two parts.

Bill Woodcock: So does anybody actually implement TSIG on clients yet, or is that kind of speculative?

John Curran: We have an answer but we don’t know if it’s ever been deployed.

Geoff, did you want to comment?

Geoff Huston: Geoff Huston, APNIC. I think Alain answered most of it. My only comment was that when you start to do kinky protocol translation work, you have to lie in the DNS at some point. And given that you have to lie in the DNS at some point, then DNSSEC is not your friend at that point.

And there’s no getting around that unless you get into, as Alain said, quite complex mechanisms of splitting apart the actual person who asked the question, your agent who is asking it for you and the authoritative source. Really kinky stuff.

But, then again, you guys should have deployed v6 years ago and we wouldn’t be in this mess.

Alain Durand: It’s worse than that, because now with Net 64, it’s essentially assumed that the sending host is an IPv6-only host. But that doesn’t fly very well in the face of reality, because most hosts are actually dual stack, so when they’re dual stack and they want to talk to an IPv4 host but there’s a NAT 64 (indiscernible), so they need to understand that the DNS is lying to them so that they should not trust it and do something else. It becomes really, really complex.

So the point is thinking that NAT 64 is going to be an end all/be all and is going to solve all the problems is at least in my personal opinion less and less true.

John Curran: Any other questions on the IETF?

We are right on time. We’ll be starting into our policy discussions. This morning we have a couple policies we’ll be talking about.

The first one is ARIN 2011-3, Better IPv6 Allocations for ISP. I’ll do the policy introduction for that and then I’ll have R.S. do the AC presentation.

Draft Policy 2011-3: Better IPv6 Allocations for ISPs

John Curran: So 2011-3, Better IPv6 Allocations for ISPs. Started out as Proposal 121 in November. AC shepherds are Rob Seastrom and David Farmer. Selected as Draft Policy on 28th of January. Posted to PPML with staff assessment on the 3rd of February, the current version is the 30th of January text. And the text and Discussion Guide is available online.

Summary: Would change IPv6 allocation policy. ISPs would be able to request larger blocks of addresses on nibble boundaries, AKA 4-bit boundaries. ISP customers of ISPs would be able to use the same policy for their requests.

ISP customers of ISPs would be able to use the same policy for their requests.

Additional allocations at 75 percent utilization. Minimum allocation lowered from a /32 to a /36 if requested.

Status at other RIRs. APNIC, similar proposal recently abandoned. Staff assessment. Staff concerns include need to make clear the new definition applies only to v6 policy. And some typographic issues.

Implementation: There’s a moderate amount of resource impact because of the tools that we use to do allocations. But it’s manageable.

Legal assessment: No legal comments.

PPML discussion: 12 posts by nine people. Four in favor, zero against.

Some selected comments: “This proposal addresses issues that we’ve encountered in planning our v6 deployment. We’ve delayed our deployment while we wait to see what happens with this proposal. It makes more sense for us to deploy IPv6 right the first time.”

“I can’t find any maximum allocation size defined in this proposal or current policy. However, this proposed policy would have the potential to allocate very large blocks. I’d like to see the language fixing the maximum size at /16 or perhaps /12. It’s just too risky to leave it completely open ended.”

“I would also like to add my support for 2011-3. A number of organizations I work with are in the same boat. And although not applicable on this list, I encourage the Board to revisit the fee structure should this policy be implemented.”

That concludes the discussion. Some comments. And there are more on PPML, obviously. I’ll now invite Rob Seastrom up to give the AC presentation.

Rob Seastrom: Thanks, John. So in a few words – so in a few words this is sort of a retooling of IPv6 allocation policy with lessons learned and losing some IPv4 thinking, which the policy, the original author, Owen, thinks is long overdue, and I happen to agree with him.

So the problem is that we have some unintended consequences of the current allocation policies. There’s a perception out there that the minimum ISP allocation is a /32.

But there’s a perception out there that is the only ISP allocation. It results in crazy things like giving customers /56s and /60s and stuff.

And it also has the consequence of forcing people to take blocks that are bigger than they want, which, in a case of an extremely small ISP has the consequence of making their costs for annual fees to ARIN go up.

So allowing those small ISPs, assuming that the Board keeps the fee schedule in something similar to what it is right now, to get a /36 while maintaining /32 default allocation allowing folks to get bigger if they need that could save small ISPs significant amounts of money.

Owen DeLong: Small correction, Rob. The fee structure would require the Board to adopt suggestion 2011.3 in order for the /36 to become meaningful.

Rob Seastrom: So here’s an outline. We’re about to get into the bad news of this. Since this retools and gets rid of a lot of IPv4 thinking, it touches a lot of places in the NRPM. I figured I’d just get it all up there so we can all have a nice discussion about this without jumping around to different slides.

Okay. Maybe not. Maybe that’s not the right way to approach this. You probably do want to open up the NRPM in your browser, because we talk about replacing certain chunks of it without reprinting those chunks which would make the slide deck even longer.

So here we go. First thing to do is get rid of Section 2.9. That’s host ratio.

(Applause.)

Despite the fact we all studied logs in high school, we probably don’t use them a lot unless we’re doing engineering stuff. So it’s just not something that people’s brains are well wrapped around and we can replace it with something simpler.

Replace Section 2.10 with the following: The term “end site” shall mean a single structure or service delivery address or in the case of a multi-tenant structure a single tenant within said structure, a single customer location. That makes it a lot clearer than what was there previously.

Now we’re adding some stuff to the end of section two. When applied to IPv6 policies, we make this clear which was part of staff feedback that this only applies to v6 policies. The term “serving site” shall mean a location where an ISP terminates or aggregates customer connections including but not limited to points of presence, data centers, central or local switching office or regional or local combinations thereof.

Add the following for Section 2.13: When applied to IPv6 policies, the term provider assessment unit or assignment unit shall mean the prefix of the smallest block given ISP reassigns to end sites. Recommended /48.

Add the following. 2.14. The term “utilized” shall have the following definitions when applied to v6 policies. A provider assignment unit shall be considered fully utilized when it is assigned to an end site. Larger blocks shall have their utilization defined by dividing the number of provider assignment units assigned from the containing block by the total number of provider assignment units.

This ratio will often be expressed as a percentage. So you take the number of things you have handed out and divide them by the total number of things in the block that you have and there’s your percentage.

This is very straightforward.

We’re also replacing some sections in Section 6.5. ISP and LIR. That means the same thing. We use them interchangeably. Nibble boundary. Everybody in here know what a nibble is? It’s half a byte. I think the current way to spell it is with an I, not a Y, but they mean the same thing, too. The reason this is interesting is because the popular notation for IPv6 addresses, the symbols are all hex digits which map directly to a nibble.

IPv6.ARPA works with delegation edges for – I don’t know what the actual correct term for that is. Zone boundary. Sorry. Zone boundary. I should know that. I work for a TLD operator.

(Laughter.)

Are on nibble boundaries, not octet boundaries.

So going to a nibble boundary, which we’re going to talk about in just a moment, the reason this is important is that it avoids all the classless delegation hacks that we had to do in IPv6 for IN-ADDR.

And it’s also good for putting that out there as a good way to chop it up inside one’s network. That’s a good example. And as the person whose phone rings at two in the morning when I’ve been out partying I appreciate not having to do bit math in my head for IPv6 addresses.

So 6.5.2 we’re making some changes. All allocations will be made on nibble boundaries.

LIRs, ISPs get /32s unless they request a /36.

And the Section C is a little difficult to understand, but it basically says that you get stuff aligned on a nibble boundary.

For the purposes of calculation in the last one, if you can justify more than one /48, count the number of /48s that you would be assigning under that policy.

Also the same thing works for subordinate LIRs. And you’re not required to design or deploy your network according to this structure.

This is just the way of figuring out the largest IP address block which you can be assigned. It’s not to say it’s not a good idea to do your subletting on nibble boundaries to avoid horrible confusion, it’s just saying that ARIN is not in the network engineering business.

6.5.2.2, qualifications. This talks about how you can get – how you can qualify for this space.

If you have IPv4, you can get IPv6. If you are currently multi-homed for IPv6 or you will immediately become multi-homed, you are eligible.

In either case, you’ll be making reassignments. That’s the key to the allocation versus assignment differentiation.

Or you can provide reasonable technical justification indicating why an allocation is necessary.

Intended purposes of the allocation, network infrastructure, allocation will be used to support.

And your plans. This is how organizations that are running a detached network that’s not part of the Internet might qualify for address space.

Subsequent allocations. So Section A, we are preserving sparse allocation. When you’ve used 75 percent or 90 percent of any serving site, you can get more. If ARIN can’t expand your existing allocations, ARIN will make a new allocation based on the initial allocation criteria. Meaning you have the option to renumber into space that will scale better. And you don’t have to renumber into the new allocation, but at least going forward you will be in space where you can get – you can get more rather than throwing more zones into routes in the DXE.

6.5.4 assignments to end users shall be governed by the same practices adopted by the community in Section 6.5.8 except that the requirements in 6.5.8.1 do not apply.

Moving right along, we’re adding to section 6.5.7, LIRs which received an allocation under previous policies which is smaller than what they are entitled to may receive a new initial allocation.

If possible, ARIN will simply expand their existing allocation rather than requiring renumber and return.

Again, this is optional. This is not required, but the idea is to fix the space going forward.

So why is this a good thing? Well, I talked a little bit about that in the beginning. There is a misconception out there that ISPs get /32s and that’s it, end of discussion, unless you jump through a huge number of hoops you don’t get more than a /32, nor do you ever get less and you just have to make do with it and put your customers into tiny prefixes, which is bad in a non-IPv6 sort of thing to do.

I’ve often made the observation to people who say why would you put /48s at my grandmother’s house by observing why wouldn’t you put /48s everywhere so you have one size of network everywhere, and, gosh, if we wasted /48s by giving one out to every human on the face of the earth, by 2020 we would have used up fully 132,000th of address space out there by doing so. So maybe we shouldn’t be economizing on the wrong things.

So allocating the range of addresses fixes this misconception. Anywhere where you generally just talk about one thing and only allude to the existence of other things, you get the impression that there’s only one thing really to be had.

So there’s a side effect of making it clear that you can get bigger address space if you qualify for it.

It also codifies nibble-based allocations, which has been a concept that’s been floating around. It’s a good idea for a long time. It clears up the ability to delegate up to a /48 as a basic minimum.

Five-year planning horizon. We are going back to the principle of giving folks more than they need rather than just enough. After all, this is IPv6 and we need to not think of this as we’re operating in a scarcity environment.

Simplified address planning, get rid of HD-ratio.

Cons. Well, there is a big problem here. Because we may waste, in the – I don’t remember from talking to Owen if this was just in the ARIN region or worldwide, but we may waste as much as four-tenths of 1 percent of the total IPv6 space by adopting this policy over the next 50 years, at which point I intend to be retired.

So with imminent run-out and the free pool dwindling to somewhere in the 99 percent range 50 years from now, run-out is surely imminent, and we need to implement austerity measures immediately.

Staff assessment. Staff basically echoed what we’re pointing out, and there will be requirements to – engineering requirements to make changes to sparse allocation tools.

There’s some errata, some changes that came in to clarify the proposal without making changes to the base meaning of it after the text was frozen.

So we have to talk about those since the AC is entirely likely to pick them up.

Restore PAU into the calculation 6.5.2.1 C. This is necessary to avoid a situation where an LIR allocates 60s to their customer but gets an ARIN allocation based on that number of /48s. It’s always the intent, but in multiple edits to make 6.5.2.1 comprehensible, it got lost. So this is the “don’t fib to ARIN by telling them one thing and then going and doing another” clause.

6.5.3.1 is from policy that was enacted after this draft was originally written. It was never the intent of this proposal to override that policy. Making a change would preserve the language of 2010-14.

6.5.4.1 restores verbiage allowing ISPs to allocate their internal infrastructure. Spelling this out is pretty much no op and it makes the policy clearer. It’s not intended to change the intent or scope of the policy.

Also deletes Section 6.9. This conflicts with the replacement language in the policy. Failure to delete 6.9 was an oversight and this change does not change the intent or effect of the policy.

So discussion. Microphones.

John Curran: Do you want to mention community networks need to be revisited because of the HD-ration loss?

So one more errata that occurs is that this policy begins to remove the definition of HD-ratio. Community networking allocation policy for IPv6 references HD-ratio. It’s presumed that the AC would somehow fix or harmonize this, so we can’t delete the definition and have another piece of the policy still reference HD-ratio.

Tim Denton: Okay. You know all the drill.

Owen, we’ll start with you.

Owen DeLong: Owen DeLong, Hurricane Electric and policy author. John, there’s enough HD-ratio terminology left in the community network’s policy to cover the needs for community networks. There’s no harmonization needed there.

Probably a subsequent policy proposal would be forthcoming from some member of the community to remove the HD-ratio stuff from community networks.

But I thought this proposal was complex enough to bite off this chunk for now and that the community networks thing was less urgent.

John Curran: Owen, if that’s the case, can we keep 2.9 in place?

Owen DeLong: I wouldn’t be opposed to leaving 2.9 in there if you think it’s still needed.

John Curran: Until we really removed it from the definitions.

Owen DeLong: But if you read the community network section and the remaining pieces of HD-ratio definition that are left in Section 6 –

John Curran: 6.7, Appendix A?

Owen DeLong: Yeah.

John Curran: And it’s also referenced there. But if we’re going to have HD-ratio, we should keep it in the definitions until we’ve expunged it from all the policy.

Owen DeLong: Okay. If that’s what you feel is necessary, I don’t have a problem with that.

Tim Denton: The gentleman in the middle.

Wesley George: Wes George with Sprint. First, I’d just like to coordinate or congratulate you both for providing the next round of quotable quotes to replace the “we will never need more than 640K of RAM.”

In general, I am not in support of this policy as written. I think it’s doing a number of good things. So I’m in support of the idea, but two things I would make as specific comments. One is you need to look at 6177 and retool this policy in order to incorporate what that says, because it basically says don’t assume /48s are the default size for all end-site allocations.

The other thing is that I think there’s enough changes going on in here that given the number of errata that have come up, this is something that really should be retooled and put back on the agenda for the next meeting so we can discuss what actually will be changing.

I think there’s too many moving pieces in what’s going on right now, plus all the errata for people to really have a good sense of what’s going on.

You did a good job of what’s being changed, but I think incorporating those things, incorporating 6177, you’ve got at least one more revision cycle before this is actually ready.

Tim Denton: Thank you. Aaron Hughes.

Aaron Hughes: Aaron Hughes, 6connect. I am in support of this Policy Proposal. I will echo some of what Wes just said in that there are some words that probably need some work.

And I have some concerns around utilization issues as well as a high-bar mark for size of request without significant justification.

But I’m in full support of the intent of this policy, and I think this is a fantastic step towards simplifying the way v6 allocations and assignments work.

I also think this is a really nice step towards matching up size categories closer to v4 categories. Thank you for your effort.

Tim Denton: Thank you. The gentleman from Microsoft.

David Williamson: David Williamson, Microsoft Tellme. I’m in support of the policy as written. I think moving to the nibble-based allocations is a good idea. I’m hoping there will be a policy submission to also do so for end-user allocations or assignments.

I haven’t followed up on that yet. Okay. Good. I am curious why APNIC felt it necessary to abandon this policy and I’m hoping that someone could comment on that.

Tim Denton: Geoff will get here in time. Okay. Geoff. Briefly.

Geoff Huston: Geoff Huston, APNIC. I’m trying to remember back exactly what happened in the meeting. But as far as I can recall, the general tenor was we’re engineers, we can do math, the reverse DNS isn’t that scary, we can run that. We don’t think we need to align against nibble boundaries.

So there was no need as far as I understood from the tenor of the conversation in the room to simplify the allocation any further than it already was and that the room and the meeting felt, as far as I was aware, that they were comfortable in the current allocation policies.

So that it was, in summary, a case of it doesn’t need to be any simpler, we think we understand what’s going on, and if simplification was the motivation, that room didn’t get there.

Tim Denton: Chris Grundemann and then an online intervenor.

Chris Grundemann: Chris Grundemann, ARIN AC. I guess the first is a question, I think everything being done here looks good. I think that getting rid of the HD-ratio makes a lot of sense at this point.

But I wonder if staff could comment on whether or not – I guess I’m asking if this is – because this is a fairly complicated policy. Is it actually necessary?

Would this change the allocations that ISPs can justify, or if an ISP came in and asked for this amount of space today, if they came in with a plan that looked like what this policy is laying out and said, hey, we have this many sites, we’re going to put this many 48s, everything that’s in the policy and lay it out as their plan, would they get the space or not?

Tim Denton: John?

John Curran: Hi. John Curran, president and CEO of ARIN. ISPs have laid out circumstances similar to what this policy would support and have been declined, because the current policy does not make it clear that ISPs can justify a size, because they’re serving ISPs as their customers who are serving ISPs.

When you do that and then you start looking at the minimum allocation that those ISPs might meet at the bottom and you work your way up to the right number, you begin to move into numbers that are below / – they’re larger in size than /32s.

In the case of someone who has credible existing customers that can demonstrate that they can’t possibly fit, it’s easy for ARIN to say you can’t get the job done so obviously we have to give you a larger size.

In the case of forward-looking, somewhat inspirational forecasts for networks of ISPs and ISPs, it becomes more difficult. We don’t have clear policy guidance.

This policy would allow indefinite recursion of providers claiming to be serving ISPs, serving ISPs of ISPs of customers.

So every time you moosh that out, you get more nibble boundary and higher up in the allocation.

So, yes, presently people are being – they’re being declined if they show up with that circumstance and being told to refer those ISPs directly to ARIN to get their own /32 allocation, if that helps.

Rob Seastrom: John, can I get one point of clarification on that? In the case of ISPs with large existing user bases who are not trying to recurse down but simply are stating that they cannot fit in the /32, they’re not getting allocations on a nibble boundary at this point. Is that correct?

John Curran: They’re not getting allocations on a nibble boundary but they can get an allocation larger than a /32 if they can demonstrate it.

Tim Denton: Here’s how we’ll go. We have the online intervener, the gentleman waiting patiently there, and then you over on that side, then I think it’s Lee and then the people behind you. So online intervener.

Unidentified Speaker: Kevin Oberman from ESnet says: I strongly support this policy, although it violates one of my pet rules that policy changes should be done in small pieces. It just does too many good things that are urgently needed. It does need some touch-up by the AC for things like 6177. Please kill HD-ratio.

Tim Denton: Thank you.

Mike Joseph: Mike Joseph, Google. I support this policy. I think it contains a package of important changes necessary to revise how we handle ISP allocations. There is always room for improvement in any policy, and I think such improvement can be done iteratively but the most important thing is this policy allows us to get to a place sooner rather than later that allows us to give appropriately-sized allocations to ISPs.

I was actually the commenter on the mailing list that was referenced in one of the earlier slides concerning the maximum-sized block.

And I do support that and in my discussions with Owen and others I think that’s something we can add. It doesn’t change – we can add that later in the Philadelphia session.

It doesn’t change this policy. But I think that as it stands this policy is still sound and should be implemented. I urge my colleagues to support it.

Tim Denton: Thank you.

Matt George: Matt George, Verizon Wireless. I’m in support of this policy. The question I have is for allocations that are larger than a /32, I haven’t seen any wording in this policy that follows the nibble boundary when an allocation is justified larger than a /32.

Rob Seastrom: I think it follows the nibble boundary as a blanket statement.

Matt George: So if an ISP comes to you – okay. Thanks.

Tim Denton: Thank you.

Lee.

Lee Howard: Lee Howard, Time Warner Cable. Congratulations on submitting what I think is the longest proposal we’ve ever had.

I want to ask a point of clarification about this proposal. I think you said that subsequent allocations would require 75 percent utilization, compared to the HD-ratio justification says something like 37 percent utilization in order to justify a subsequent allocation after a /32, which is one of the advantages the HD-ratio is that you can be – you can use an ISP, you can allocate more sparsely in order to have good, clean network engineering along your address allocation boundaries.

So, yeah, I think that’s where I saw that number. Am I correct that’s what that means?

Rob Seastrom: Owen, do you want to respond to that?

Owen DeLong: I would like to. It actually comes close to that, Lee. But the advantage of the 75 percent is it’s easier to understand, and also it turns out that at the point where you’re talking 37 percent in the HD-ratio, where that actually becomes useful is in managing POPs that are wildly desperate and disparate in size, and this provides a safety valve in that you have any single POP that hits a 90 percent utilization you still qualify for an additional allocation even if you’re not at 75 percent overall.

Tim Denton: Is your question answered?

Lee Howard: I think perhaps I should get offline with the authors and shepherds because I think we’ll need to go into it a little bit more detail. So if one POP is – uses address space, if I’ve got one /44 assigned to one POP and, oops, I’ve used 90 percent, then I need another /24?

Owen DeLong: What you would get instead is a replacement /20 that you could – I mean either you’d get expanded to a /20 or you’d get a /20 that you could, through attrition, renumber into over a longer period of time with no requirement of return.

Lee Howard: So I have some concerns about this particular section that I need to talk to the authors in a little bit more detail overall. So I don’t know whether I support it – so I think generally good; want to talk through some of those details a bit more.

Tim Denton: Okay. Dan Alexander.

Dan Alexander: Dan Alexander, Comcast Cable and ARIN AC. John touched on one of the –

Tim Denton: Start with whether you support it or not.

Dan Alexander: I generally support this. I had a lot of apprehension in the beginning but I’m coming to terms with the new math, and it’s starting to – I’m starting to become a fan of it.

But John touched on one of the two concerns that I have. The one being that recursive nature of ISP allocations to ISPs and to ISPs.

And it strikes me that one of the hang-ups with the smaller ISP is not going directly to ARIN is typically because of the fee structure.

And I think it would be a better approach to fix the fee structure so we could flatten out the allocation structure a little more and have more people going to ARIN than this recursive nature.

Because I think it would help clean up Whois a little better, too.

The second concern I have about this is I think it’s Section 6.5.7, which is the renumber clause for if they get the – if they redo their initial allocation. And I had mentioned that on the mailing list, because while it’s not very visible in the Internet, there’s a number of networks out there that are quite widely deployed with v6.

And to put that burden on people at a time where we should be pushing the deployment is not a very good step in the right direction, I think.

Tim Denton: Yes, go ahead. There’s a question for you, Dan.

John Curran: Dan, question. So you talked about flattening out the registration, possibly leading to better Whois data. I guess I’m wondering: The policy envisions indefinite recursion.

Owen DeLong: Not exactly.

John Curran: If it has a limit, I can’t find it.

Owen DeLong: There’s no limit written in the policy, but if you’re recursing small numbers of ISPs, the ARIN fees rapidly become impractical for much depth of that recursion.

John Curran: Right. So there’s no clearly stated limit, I guess.

The question is: Is there a certain structure or do you see this as an issue to propose a certain structure? Should there only be ISPs of ISPs? Should we allow three tiers? Should there be a limit on maximum size on how many ISPs can assign to sub ISPs as can fit inside a /16? How do you propose it should be improved?

Dan Alexander: I don’t think I’ve settled in on a direction. I mean, at most one layer deep would be viable.

This might cause some cringing in the room, but ISP allocations to ISPs, to say no, that’s not realistic. If you are an ISP, get your allocation from ARIN. That’s another approach.

John Curran: Just asking.

Tim Denton: All right. Thank you. Next.

Bill Smith: Bill Smith with PayPal. I’m neutral to negative, but only slightly negative on this policy. Let me state at the outset I’m quite familiar with scientific notation. Unfortunately, there are many people who are not.

And now moving on to a completely different subject, having nothing to do with scientific notation, I’d like to talk about the ITU.

In particular, they’re paying quite a bit of attention to activities around allocation mechanisms.

Anything that is seen as increasing a size of a default allocation could be used as an argument for the ITU to take an increased role in the Internet community, generally, and I think that’s a bad thing.

I’m not saying this policy would do that. But it could be perceived that way and presented that way at the ITU.

I just returned from such a meeting in Geneva last week. It’s an extremely bizarre environment. So I would encourage the drafters of this policy and this community to take that organization into account.

I’d also encourage the other RIRs who are present to work and attempt to come up with a uniform harmonized policy in this regard.

These types of things are being used against the community, and I think you may not be aware of that.

So I’d just like to bring that up. Thanks.

Tim Denton: Could I raise a point of information with you. The concern I have with anything relating to the ITU is that almost anything will do. Any excuse will do. Why in particular is the changed size of allocations of concern to them rather than more than any other kind of thing that we do?

Bill Smith: It’s not. I’m just reporting to you that things that you do have an impact. If you do it without paying attention to that, to the ITU, in some manner, okay, the greatest technical solution that you come up with, okay, may be turned against you in an argument that has absolutely nothing to do with logic. But it’s important to – I believe it’s important to pay attention to it. That’s really my point.

Rob Seastrom: We’re actually quite aware of that which is why I made a point of noting that we are in fact profligately wasting 0.4 percent of available space.

Bill Smith: I was well aware of that. That comment, though, in the confines of the ITU will be taken in exactly the opposite manner that you intended it.

They will look at it and say that is profligate waste. It is illogical, but it is how it will be taken. So just be cautious about how you present these things. Okay? I don’t agree with their positions.

Tim Denton: Two questions. John Curran.

John Curran: So in light of that, is there particular changes to this Policy Proposal that you’d recommend, or would you recommend not acting on this Policy Proposal for that reason?

Bill Smith: I’m trying to point out my point of view on this. Others have spoken and said that there’s some language issues, things that need to be clarified. I would suggest that more time be spent on this and perhaps it come up at the next meeting for review and there be attempts to harmonize this across other RIRs as well.

Tim Denton: Dan, you’re out of order.

Dan Alexander: I was going to add to that and respond to your request, your inquiry about what could be done.

Tim Denton: Briefly, then.

Dan Alexander: The perceived argument is always about the inequities of the allocations. And to point – to touch on what Bill was saying, I agree with what you guys are saying.

For us to try and jump through hoops to accommodate them is pointless. There’s always going to be an issue with anything that we do.

But to have a more harmonized approach across the multiple regions where we’re all speaking as one voice takes away a fair amount of the argument.

Tim Denton: Thank you. So right now we’re just in order down by that microphone. So carry on.

Andrew Dul: Andrew Dul, Cascadeo. I support the policy as written with the changes and additional massaging that needs to be done.

Having helped start the process with Owen a little bit after the last meeting, there is one area that I am a little concerned about, and that is large capture of address block.

Without regard to specifically what we call waste, I think there is some possibility that there could be some game play going on to try to capture a larger block than perhaps is necessary or needed and could be justified appropriately under the policy.

So I would support a cap of an initial allocation of some size. I don’t really know what that size should be.

But having some sort of cap with perhaps an appeal process or something might be a way to avoid some situation where an organization uses the policy to capture an extraordinarily large amount of address space.

Rob Seastrom: What would you consider extraordinarily large?

Andrew Dul: Greater than /20.

Tim Denton: Next.

Unidentified Speaker: I do support the concept of this. I think the initial and subsequent allocation policies definitely could use a rewrite.

The concern I do have, though, is that we’re looking at – given the size of this, we’re probably looking at a year or so maybe for this to get actually passed.

And there’s actually a piece of this I think could be really useful very quickly, and that’s something along the lines of 6.5.7 allows – so many of us – or many providers wrote their addressing plans a few years ago and are now getting to the depths of actually deployment models.

I think a lot of people will find there’s not enough space in their initial plan to actually do what happens in reality. So there does need to be a way to say – without utilization go back and say, hey, here’s my realistic plan, and something quickly to allow you to have enough address space so we can roll out across service providers.

It would definitely be helpful.

Tim Denton: Mr. Huston.

Geoff Huston: Geoff Huston, APNIC. I’m neither for nor against this proposal, but I’d like to help Jason there in speaking in defense of the HD-ratio.

The whole idea of the HD-ratio was actually in response to the original v4 address utilization rules; that when we noticed back in the mid-’90s that we were running out of addresses, I think it came from the IAB that someone said we need to increase the utilization.

So across the board the observed address utilization was 10 percent; let’s make it 80 for everyone. The reason we did that was life was scarce and hard and we realized at the time that making it 80 percent for everyone was going to be hard, but it was going to be really hard the bigger you were.

Christian Huitema studied this as part of a workup he did with some collaborators in France Telecom, and when they looked at the address plan for the telephone networks, what they found was that for the very, very big networks they were unable to achieve address or telephone number utilization densities the same level as smaller.

And the relationship they found experimentally was logarithmic. In other words, twice as large meant that you really achieved the square of the proportion of address efficiency.

In other words, the bigger you were, the harder it was to make address plans work. So the HD-ratio was their experimental observation of what was achievable.

When we came to v6, the fundamental idea in the heads of many folk in v6, I won’t say including myself because I wasn’t there, but I certainly remember Steve Deering saying addressing plans should be easy because we have heaps of addresses. It should not be hard.

Any kind of approach that makes large networks work intolerably hard to make address plans work and achieve 75 percent efficiency is not using v6 well.

We have addresses; let’s make them work. The HD-ratio was part of the addressing plan because it was – it was effectively built in. The bigger you were, the lower the efficiency you were able to achieve when you needed more addresses.

The original target HD-ratio was based on .8. And what we found were – Thomas Narten and I did this study – the big networks would consume a /4. This seemed a little bit weird.

So in looking at this we said how about if we make the HD-ratio slightly larger, and I think we came at around .92. We’ll still get at least 200 years of life out of v6, but if we keep that HD-ratio, big networks like Time Warner Cable and so on don’t need 75 percent, they don’t even need 30 percent, they can do services to ISPs who are services to ISPs, the bigger they are the larger the arbitrary did, because the HD-ratio takes that into account.

If you throw out the HD-ratio you’re going to be here in this room for the next five years inventing all the little rules you need about all the sub cases of how very large networks are so diverse they can’t achieve the required base level 75 percent utilization.

The HD-ratio was intended to make your life easier. The math is hard, but the result was meant to be a beneficial one for everyone. Thank you.

Tim Denton: Aaron.

Aaron Hughes: Aaron Hughes, 6connect. Wanted to make a point about utilization. I think if we’re suggesting planning and allocating on nibble boundaries, we need to account for utilization for service providers for tie-downs.

I don’t exactly know how to text – appropriate text for what this should be. But in assigning what this methodology – the second we tie down a grouping of any nibble boundary, a grouping of /48s, we tie it on to /36, we use one /48, it’s used.

Same thing for /32s to /28s. We need to account for it in some shape or form. I don’t know what it is, but it’s not percentage.

Tim Denton: Thank you.

Jason.

Jason Schiller: Jason Schiller, UUNET, Verizon, and the NRO NC. I mostly support this proposal. I have two points of contention that I guess I’ll talk about those first and then some other points I’d like to make.

The first point of contention. Somebody else at the mic, I don’t remember who it was, previously stated about the case where an ISP is making downstream assignments to another ISP. I agree, plus one, that this is bad form. We probably shouldn’t be doing that.

My second concern. I had an extended conversation with Owen yesterday about the definition of “end site,” where you have a single physical location that’s a multi-building campus. Each building can be considered an end site. It’s hard for me to justify a multi-building campus needing more than a 48, but I’m told this is common practice in terms of number of subnets; that it’s common that you can have tens of thousands of subnets in a building.

If that’s the case, then I would certainly support this. But I have not heard that’s a common practice.

That type of a calculation is also a little bit problematic for me because it’s very hard for me to know how many buildings my customers currently have. So I’ve done some math on the Verizon business side of the house to look at the number of customers we have, assuming that each customer has only a single building or we define an end site as a physical location for which a circuit goes to.

And I would end up getting quite larger than I currently have.

I know the question on the table is will this change the amount of space that ISPs get. And on the Verizon business side, it certainly would.

I’d also like to point out the reason I support this is because you have heard me come to this mic time and time again with v4 policies concerned about fragmentation and the size of the routing table.

We, UUNET, WorldCom, MCI, Verizon Business, have had a serious problem over the years where we were growing very rapidly, we were getting as large a block as we could get. We were fragmenting it up for our internal aggregation scheme. And then when we would run out in a particular region, we would go back and get more space and stack that on top of the existing allocation and fragment it again for all of our regions. And repeated many, many times over.

With a large network, with many hubs, with many edge routers, we have a lot of internal disaggregation or deaggregation.

When it came time for us to do v6 we said we’ve got the potential to get much more address space, and we can do things in a more sane fashion and have better aggregation.

We spent easily six months considering our numbering plan for v6. And we considered a plan where we would aggregate at the edge router, the hub level, the regional level, the continental level.

And we submitted a request based on this information, based on the current number of customers that we had and asked for space to cover it, and it was not fulfilled.

We got less than that. And we did not include nibble boundaries because we were going to do the hard problem of figuring out how to allocate the DNS. We rounded up to the nearest power of two. So this would give us even more space than we previously requested and were denied.

On the other hand, even if we end up getting a /16 or a /12 or even a /10, and there’s only a small handful of extra large ISPs, how much space is that really burning really in the grand scheme of the total v6 address pool?

So, like I said, I’m not sure I agree with the definition of end site. I’d like to hear people comment on whether or not they think they need thousands of subnets per building. That would be certainly useful to me. And I don’t support the idea that ISPs should be making downstream assignments to their ISP customers of /32 or larger, nor should they be making assignments to downstream ISP customers that have downstream ISP customers.

I think this becomes very problematic. If you’re an ISP, you should easily be able to get a 3/2. Or if people think they want a smaller /36, so be it.

But otherwise I generally support this policy. Thank you.

Tim Denton: I just note that we have ten minutes left for discussion and voting. So keep it reasonably crisp.

Alain Durand: Alain Durand, Juniper Networks. I’m opposed to this policy. If Christian Huitema was the H of the HD-ratio, then I’m the D of the HD-ratio when we created this a number of years ago.

As Geoff said, it was meant to take into account large service provider. We could not achieve the global efficiency.

It was also meant to take into account the different levels of delegation that you could have within your address space and essentially provide an aggregated view of all of that.

So I understand that might be difficult to find the log key on the calculator to do the math. But what you are doing here is essentially recreating exactly the same thing the very hard way by going down to all the levels of aggregation and try to reconstruct what the HD-ratio was giving you as an overview. That was my number one comment.

My number two comment is you want to repatriate the ratio and you provide us with this very long and complex policy. I think that you assess moving the complexity around and I would rather support a policy that will say you may have had an initial allocation that is not big enough for you, it’s a simpler way to get a bigger one, things like that.

Provide ease into growing what you already have in a much, much simpler way than what is proposed here.

Tim Denton: Mr. Farmer.

David Farmer: David Farmer, University of Minnesota, ARIN AC. In response to Jason’s question about large end sites and stuff like that, the thing you have to remember is in very large end sites, they need to do the same kind of aggregation and hierarchy that you’re asking for your ISPs to be able to do.

So they may not actually need thousands of live subnets, but you need the hierarchy, which creates thousands of potential subnets, but the hierarchy, you have a low-density use of those subnets, but the hierarchy makes it manageable. So same thing that you want to do in your ISP network large enterprise customers need to be able to do in their local networks. And I will leave it at that.

Tim Denton: Thank you. We have one remote participant. And I’ll make you the last speaker after the remote participant.

Scott Leibrand: Joe Maimon at CHL is opposed to the policy as written. Apparently ISPs are currently the only ones who almost never get more space than they can use, and this policy would help adjust that, but the large number of moving parts and complexities involved in this proposal concerns me. I’m also concerned that there seems to be too much reward to ISPs who make larger and larger customer assignments.

Tim Denton: Sir.

Alan Chen: Alan Chen, Time Warner Cable. So I really have just a general question about this. What was the – what was so broken about the Section 6.5.2, I guess, for getting subsequent allocations that we would have to basically destroy it at this point?

Tim Denton: Owen.

Owen DeLong: Section 6.5.2 is based entirely on the HD-ratio stuff, which has not worked for a number of people as well as some of the people who so strongly support it seem to think it should have.

There are a number of ISPs that haven’t really had to look at 6.5.2 yet because they haven’t gotten there. I know of only one ISP that’s had to look seriously at 6.5.2, and I can most definitely assure you, if we were to come back under 6.5.2 as it’s currently written, we would be coming back under 6.5.2 probably on an annual basis for at least the next five years.

And I don’t think that is ideal.

Tim Denton: Okay. Rob Seastrom.

Rob Seastrom: So I was watching for references to 6177, because I sort of anticipated someone might say something about that. I heard both Wes and Kevin.

I did in fact read 6177 and I did not note any phrase along the lines of shall not allocate /48. It seemed to be more of a – my take-away was don’t assume it’s a /48.

And the text that I saw in this policy was don’t assume it’s not a /48 which did not seem to be in conflict to me.

I would welcome any wordsmithing or any input from any of you or anyone else who is interested in adding something in that makes it clear that we do not consider this to be in opposition to 6177.

Tim Denton: Okay. I think the time’s now come to take the vote on whether to propose this to the AC.

John Curran: Thank you, R.S.

Tim Denton: Thank you.

(Applause.)

Tim Denton: To propose whether this should go to the AC as the advice of the room on this proposal, first we shall ask those in favor of this Policy Proposal to signify their assent by raising their hands. As written. Those against the proposal as written would you signify, please.

Have the votes been tallied? Can they put their hands down? Yes. Thank you very much.

Okay. So 2011-3. Total number of people in the meeting room and remote, 116. In favor of as written were 20. And against, 17. So I’ve been asked – Bill Darte?

Bill Darte: I like your question yesterday, in principle is this something that people favor and with –

Tim Denton: Yes. So the question that I shall now ask the room: Are those in favor of the proposal in principle and that further work should continue on it.

So those in favor of the proposition that they want to see this move forward in principle with further work to be done on it, would they signify by raising their hands. Votes have been tallied.

Votes who do not favor in principle any further work on this proposal, would they please signify by raising their hands.

Can they lower their hands now, Bob?

Bob Stratton: Yes.

Tim Denton: Thank you. So in relation to the idea that further work should be done on it and we move forward, the vote was 55 in favor and three against. Thank you all very much.

John Curran: Thank you. Okay. That concludes our policy discussion for the morning. Or at least that policy. We’re going to have a short break and we’re going to come back here at promptly at 11:00 where we pick up on a report and another policy discussion.

So we are at break until 11:00.

Reminders: If you are missing this wonderful North Carolina hat, please find Susan. She’ll have it. And I’ll see you all back here promptly at 11:00 a.m. Thank you.

(Break.)

John Curran: We have an RIR Update and we have a Policy Proposal to discuss. We’re going to get those both in before lunch.

I’m going to start out with the policy update, and that will be Axel Pawlik coming in to give the update for RIPE. Not policy update. Sorry. RIR Update.

RIR Update - RIPE NCC

Axel Pawlik: I’m Axel Pawlik. I’m the managing director of the RIPE NCC. And I’m third together with Dan, thank you very much, in the foosball tournament. Yay.

(Applause.)

I have said before that’s the highlight of the ARIN meeting for me, really. So I’m still on my emotional high from the Sunday evening. And to show my gratitude also for just having me in the sun and all, I decided not to bore you with all the fancy colorful up-and-to-the-right Internet graphs about the number of tickets we do and the number of staff and the number of meetings and how well it’s all going, but to share some thoughts that we have had over the last couple of years about the change, the transformation, the discontinuity, running out of IPv4, and then, oh, my God, what?

So apologies to those who have seen it before. We have started to think with our management team internally and with our executive board about what is the RIPE NCC going to do after v4.

And we found the three pillars there, basically being a trusted source of data. And obviously as the registry for internet numbers in our service region, we know the numbers and we have lots of data there, and we should be a little bit more aggressive about it and just position ourselves accordingly and show people that we have that and people can use that.

Resource lifecycle management. Obviously we’re not giving out addresses all the time. Only we also receiving some back and then we need to do some due diligence on those and certification of numbering resources, stuff like that, comes in there.

And the last is developing the role of the RIPE NCC or maybe redeveloping the role of the RIPE NCC.

The NCC stands for Network Coordination Center. The place was set up in ‘92. That’s nearly 20 years ago. Party coming up soon, huh?

So it’s a Network Coordination Center and we didn’t know about regional registries at the time, so we did other stuff that used to be useful for the Internet community in our region.

We thought that’s something that we really need to push to the fore a bit and really develop it and talk about it and see that we do things that are useful.

So I promise not to show any up-and-to-the-right graphs.

Expectation. The work emphasis will change. Of course we will still do work and you’re not really meant to look at those graphs in any great detail.

That’s basically saying, yeah, we panic, too, a little bit. Especially Andre over there, registration services manager, panicked for a little while when after the Miami event when IANA ran dry, there was a lot of interest suddenly again in all sorts of numbers that we have to offer. But it cooled down a little bit, but it was not as bad.

But now that APNIC is going to run out of IPv4 really soon, I guess we’ll see another spike there.

But basically, yes, the overall emphasis is away from allocation and more towards registration, maintenance of registry and similar things, and the bulk of our work will be in activities that are non-allocation-type activities.

Related to our membership, what are we doing. What we are doing apparently is useful to our members. That’s why they once a year okay our budget and the charging scheme.

They more or less, most of them, pay happily. So we must be doing something right. But what is that? So we’re looking at this and say, look, we promised many years ago we wouldn’t be a lobby organization.

We are not a lobby organization in that sense, but, of course, we do go out and talk to policymakers, regulators, police force and the like.

We do that sort of on behalf of the overall Internet community in our region. So you don’t have to do that as our members but we do this and this way we manage expectations and protect the bottom-up industry server regulation process and stuff like that.

Of course, as members you have needs. You want us to do things, so we need to understand that. So we have done a couple of member surveys, membership and stakeholder services over the last 10 years as far as I remember.

And the next big one is coming up. I think we’re launching it at the next RIPE meeting in a couple of weeks. Basically to understand what our members are expecting from us, and then to do those things.

Of course, we will continue to maintain important infrastructure as we are currently doing in the number registry, obviously the root nameserver clusters that we operate around the world, various data repositories of data that we have been collecting for nearly the last 20 years.

And, of course, new tools. So if you tell us what to do, then we’re happy to do that.

Some examples. Source of data activities. The registration data quality. It’s an activity that has been going on for a couple of years already. I was just looking at it, making sure that we have the right people as contact points and the like.

2007-1 Policy Proposal from a couple of years ago already basically telling us to have – ensure that we have some contractual relationship, maybe transitory – transitively with the holders of PI space.

So, again, quality of data in the registry. Resource certification obviously is one. Reputation services. We’ve started to talk to our members in training courses. Also we gave a bit of a presentation based on that at the last RIPE meeting in Rome, basically looking at reputation of address blocks, holders of address blocks in a way that says, no, those guys, yeah, they do pay the bill so supposedly we know who they are, but they never keep their stuff really up to date so they don’t get any gold stars.

Others we have frequent contact with and we did lots of auditing into their stuff, and they are really up there, top-notch. They get three gold stars, really, whatever that means.

But there’s some interest in us doing such a thing. So we are looking at that very carefully.

What else? Certification I mentioned. The good thing is that we implemented and we the first of January opened the service. And by now 10 percent of our members have done something with it.

And there’s a bit of a graph there saying that they have played with the system. They have set up their certificates. They have set up their ROAs, something that’s happening there that’s surprisingly positive. I expected a slower start.

But law enforcement, we talked about that. Lots of tools that we have been playing with and setting up over the last two years, I think. RIPE Labs there as a meeting place for interesting stuff. RIPE Atlas, the new measuring network that we hope to be converting from a pilot into a proper service soon. Certification again.

RIPEstat is a proposal or a pilot currently in development to give access to all the data about address blocks that we have in all our various bits and pieces in the company and on labs as well to be seen.

So obviously the challenge is for the next two years not to fall over. Currently our charging scheme is based very heavily around your address holdings over time and the like, and as we are – mostly IPv4.

As we’re not allocating much IPv4 over, in three years’ time that needs some looking at. And we have ideas on how to do that. The basic idea is to do changes carefully and slowly so that the whole setup and the whole balance between organization and membership and overall community and other stakeholders is stable. That’s the most important thing.

Well, here are the usual things. There’s a RIPE meeting coming up and it will be in May and it will be in Amsterdam. I promise it will be nice and sunny and warm, not as warm and sunny as out here, but there are other things to look in Amsterdam as well.

So you’re very welcome, obviously, and we expect you in droves.

Last service announcement. To those of you who were expecting Paul Rendek to party with and have fun, in spite of him being a lifetime Platinum member of Air France or Telum or something, they wouldn’t let him on the plane and so he’s not coming. Sorry about that.

The rest of us will stay here. I brought a couple of Board members. Some of them had to leave or couldn’t come as well. Because we’re doing more strategic research, strategic thinking, we’re doing a bit of a Board retreat here on the Thursday, so don’t be frightened when you still see us lounging at the pool afterwards.

Thank you. Any questions?

John Curran: Any questions for Axel?

Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension

John Curran: We now move into the policy discussion mode, which is right on time. So we have the next policy up for discussion is Draft Policy ARIN 2011-5, Shared Transition Space for IPv4 Address Extension.

I will be doing the introduction to this Policy Proposal, and then I’ll have Chris Morrow of the AC come up and give the AC presentation.

So this Policy Proposal originated as Proposition 127 in January 2011. Shepherds are Stacy Hughes and Chris Morrow. Was selected as a Draft Policy on the 28th of January. Was posted to PPML with staff assessment on the 3rd of February. The current version of the text is 20 January. And the text and the assessment online is in the Discussion Guide.

This proposal would reserve a /10 in ARIN’s Whois similar to blocks reserved by RFC 1918 and 3068.

The block is to be shared by anyone who wishes to use it with no further registration actions required by ARIN. The space is not to be routed on the public Internet.

No similar policy or proposals at the other RIRs.

Staff comments or concerns: The proposal would have ARIN acting as the registrant for a single IP block and maintaining it without anyone knowing how it’s used in truth.

This would likely generate a great deal of abuse and spam complaints to ARIN since we probably would be the party registered.

It is unclear whether ARIN would need to set up nameservers for this block to provide reverse DNS or what the contents of that would be.

In keeping with the spirit of RFC 2860 with respect to assignment of specialized address blocks, ARIN staff will consult with IANA and the IAB regarding implementation of this Draft Policy. This is not a role traditionally done by an RIR, and so some liaison is necessary before I know how this would be actually implemented.

Resource impact: Minimal.

Legal assessment: No legal comments.

PPML discussion: Lots of discussion. 56 posts by 15 people. Five in favor and two against.

“What’s the cost? We lose one /10 that could have been assigned or allocated as unique space for a handful of ORG or potentially one large one, but we gain a shared space that can be used by all ISPs with the need for it the world over. The proposal appears to provide the greatest good.”

“Any entity that wants a /10 for their own projected use wants it when there is no ARIN /10 available to anyone. Until that point they will continue to make and justify requests just like always. The draft has zero conservation effect. I don’t support it.”

“I do think it’s completely reasonable to ask some nontrivial number of service providers to come forward and announce they will use this block if allocated by ARIN. You can argue about the overall merits of the stewardship of this proposal, but without a reasonable number of service providers announcing they would use this block if it was available, it’s impossible to defend the stewardship of this proposal in my opinion.”

That’s a subset of comments to some of the issues raised. The full comments, discussion, are contained on the PPML.

That concludes the introduction. I’ll now ask Chris Morrow to come up and give the AC presentation.

Chris Morrow: So Stacy and I spent a little bit of time on this and read a bunch of the list. Look like there’s over about 100 posts if you include the original proposal and this one.

So, again, the history. Sort of the overall context for it. What’s the point of it. And the links to go read it, which you should have anyway.

The summary basically, as John said, set aside a /10 for service providers to use for things related to CGN or internal management address stuff. Don’t use it on the public network, don’t leak it across AS boundaries, things like that.

And a couple of interesting points to keep in mind is it’s not clear that from the proposal and from other work that ARIN can necessarily set aside something in a global manner like this, especially not without going back to the IETF or IAB to ask them if they want to object or officially make it part of the process for them. So we should keep that in mind when we go forward.

My colleague from Google, Mike, mentioned that this was – a similar policy to this was actually discussed in APNIC region, which I missed. So this slide’s not completely accurate.

But it got – as Geoff would say – sent back to the mailing list in a polite fashion. Is that right? Discreetly. Yes. Whereas we just reject them.

The staff assessment work, sort of there was some questions from folks in the field about why is it that ARIN needs to consider doing anything at all for this right after they assign it to some entity, be it themselves or some other thing.

I think John’s discussion about do we need to do PTRs, do we need to deal with abuse complaints, is that going to be more or less what ARIN gets today. It’s not clear to me, but staff seems to think there’s something to think about.

And I’m sure they’d be happy to hear other options. As I said, there’s about 100 posts from about 20 people. I counted three that were clearly for the proposal, one who has said, Well, I really don’t know, but I’ll give my opinion in some other random fashion. And 96 posts about how people would never stop asking for address space just because this /10 existed.

So it wasn’t – not clear-cut, at least. And I think some discussion from the audience would be great to have. I know there’s a couple of folks from – cable MSO-type folks who have an opinion as well.

And that’s it for us, I think. Any comments?

Tim Denton: Don’t everyone speak at once.

Alain Durand: (Speaking French.) Do you want me to keep going like this?

Tim Denton: I think you better switch to English now.

Alain Durand: Alain Durand. And I’m against this proposal. And the reason is it doesn’t work. If you look at what hosts on the Internet have been doing for many, many years since 1918, has been written, is that they have outcoded it.

So many applications, many kernels, many software actually have very specific idea of what an RFC 1918 address is, priority address. And they make some decisions based on that.

So they could say, oh, this is priority address so I’m going to assume that I’m in a private domain and then do X. Obviously the global address I’m going to assume that I am on the outside and I’m going to do Y.

The best example of that is 6-to-4. You take a PC, Windows machine, and if it has a global address, it can turn on 6-to-4. Now, think about that same PC; that with this address, it will think it’s a global address. It’s not a private address. So I’m going to turn 6-to-4. I turn 6-to-4, and then what?

My packet goes nowhere because it actually is a private address. So what you do there is we essentially break a number of applications by doing something like this, and in particular you break 6-to-4 and you increase what is called the IPv6 breakage that we’re trying to measure in the world IPv6 day. And I think it’s a really, really bad thing.

Tim Denton: Thank you.

Mr. Howard.

Lee Howard: Lee Howard, Time Warner Cable. I favor the proposal. I disagree with several of Alain’s breakage cases, but the problems that I see are that we’re going to have to do carrier grade NAT.

Carrier grade NAT is going to break some things, and there’s no way to make it happen without some kind of block used internally, and if our choices are each ISP has to designate some of its own globally unique address space for inside the carrier grade NAT or each ISP can use the same block for inside the carrier grade NAT, then I know which one I believe is more efficient, and therefore it’s as much as I don’t want to have to do this, I think we have to.

Tim Denton: Thank you.

Nodir Nazarov: I’m Nodir Nazarov from Cablevision Systems. Huge, huge in favor for this proposal. I spoke with a few of my colleagues and I sense some hesitation, and the primary reason for the hesitation was that it will slow down IPv6.

This proposal was – it was explained to me that it was originated as to fix overlap issue, but the side effect of the proposal, the positive side effect, it increases 1918 space in my view and it helps with the MSO, smaller MSOs. It will not help larger MSOs like Comcast who has large, large needs, but small-to-medium MSOs will benefit hugely.

And otherwise they will have to resort to ask ARIN for more space. Now they don’t have to do it.

CGN is going to be work. I see this proposal to be a bridge before we get to full IPv6 deployment. That’s pretty much it.

Tim Denton: Thank you.

Mike Joseph: Mike Joseph, Google. I oppose this proposal. I think creating extension of RFC 1918 space is outside the scope of ARIN’s purview. I think we’ve already seen, based on APNIC and IETF declining to pursue this action that it doesn’t seem to have global support for us to do this in isolation, which does have global impacts as Alain pointed out it breaks 6to4 which is a major impact on IPv6.

It potentially puts a burden on CPE manufacturers to update their code which we all know won’t happen in time. But if they do now they’re doing so because of action taken exclusively within the ARIN region. This proposal won’t cause a decrease in demand on the ARIN free pool.

I respect my colleagues at Cablevision who I know have an intention of using this. But I can’t say the same thing for every MSO and we’ve already seen at least one particular MSO get a very large allocation quite recently, and I don’t see that trend stopping before pool exhaustion.

So I think all those combined with RFC 1918 is a perfectly fine use for carrier grade NAT, conflicts notwithstanding, I can’t support this proposal.

Tim Denton: Thank you very much.

Mr. Hughes.

Aaron Hughes: Aaron Hughes, 6connect. I am in support of this proposal. NAT 444 is certainly going to happen or CGNs are certainly going to exist. There is no question. There are tons of legacy hardware that will not be replaced before run-out and v4 is going to have to continue to be supported for many years as we all know.

There are some challenges with this and there are many providers from very small to very large that cannot allocate 1918 space that’s unique from their customers. There really isn’t another solution other than to have providers. MSOs continue to request more unique v4 space.

The purpose of this proposal is simply to get that stopped so that there is one set-aside allocation for that purpose and we don’t continue to have MSOs continue to waste more than a /10 for this purpose.

The DNS comment, yes, something needs to be done. Maybe it’s call dot your dot local dot provider dot something. But it should never actually be in an email header. It’s meant to sit between 1918 space in a CGN.

Tim Denton: Thank you.

Wesley George: Wes George with Sprint. I’d like to echo a lot of the comments that my colleague from Google brought up.

I am still opposed to this proposal. I think if I was going to summarize the things that make me still opposed to this proposal, I think all we really have is some anecdotal evidence that 1918 as a whole is not going to work as a suitable space for this NAT.

Yes, there are lots of devices out there that use lots of different parts of the 1918 space. But I think we are very, very heavily focused on the problems with that, even though it is largely a long tail problem.

I think that if most of the folks who are actually considering how they’re going to implement NAT 444 in their networks would look at the makeup of the devices that are in their networks they would find there’s some subset of that space that is usable.

And that they may have to work with some customers in order to make some changes, but there is ways to minimize that breakage.

Owen’s going to tell me otherwise, but what I’m going to say is that’s my viewpoint, and I have not yet been convinced otherwise by what Owen said, so we probably shouldn’t waste time with that discussion here.

If someone else wants to try to convince me of that, that’s fine. But I’m just trying to save us some time in terms of discussion.

Nothing personal.

Owen DeLong: That’s not actually what I stepped up to discuss before you stepped up to the microphone.

Wesley George: Right. And that’s what I figured, but I thought I would say that. But the question that we really need to ask and answer here is: What happens if we don’t do this? What happens if this policy is not passed?

And we’ve already heard from a couple of folks like Aaron who basically said big bad ISPs are going to show up and request more than a /10 of space to do what it is they need to do here, and I do not – I have not and still do not buy that argument.

I think that if there was justification for ISPs to get additional space they would already be doing it, because getting more space is preferable to doing NAT.

I think that ultimately I would prefer to see this continue as is so that we have sort of a deterministic exhaustion, and then let the ISPs figure out what is the best solution for them, whether it be use 1918 space or whether it be free up some of their existing space to use as an inside NAT pool. But I don’t think that we need to be helping.

The last point I’ll make here is that in looking at my own network application, I’m not certain that a /10 would be enough. And therefore this is not fundamentally better for my application than were I to use multiple instances of 1918 repeated across the network.

Or to squat on a larger block.

Tim Denton: Thank you. Owen, I don’t know in what order you got up relative to these, but I think they’re ahead of you.

Owen DeLong: I think I was actually two people ahead of Wes.

Tim Denton: In that case –

Owen DeLong: Owen DeLong, Hurricane Electric. I actually got up to address Alain’s original comment about breaking 6to4. Deployed where this is intended, it actually has no effect whatsoever on 6to4 because it’s not in that decision chain. Deployed where this is intended, it sits between the customer premise NAT and the carrier NAT and is used just to provide non-conflicting intermediate space in between those two points.

That is not part of any 6to4 decision that should be made. There should be no 6to4 tunnelling occurring anywhere in that zone.

And so claiming that this breaks 6to4, which is already arguably one of the – probably the second-most broken thing in v6, next to Teredo, is sort of absurd. It’s not intended to be applied anywhere that 6to4 is relevant. And thank you, Wes, for thinking what I was going to say.

Tim Denton: Sir.

Jason Weil: Jason Weil, Time Warner Cable. I do support this proposal, at least I think we do need space, unique space for anybody that wants to deploy carrier grade NAT between the home gateway and the NAT. It makes deploying that less cumbersome, especially if you’re completely out of 1918 space, which many providers are today.

I won’t go into all the details. If you want some exciting read, you can look at the v6ops list. I think there’s like 700 or 800 posts over a year of op lists. I definitely think it’s needed.

I think the real question, though, is if people can go out and get public space today for this use, and all those allocations are greater than a /10, then it’s just good stewardship to have – make sure everybody uses one /10 instead of everybody going out and justifying space that’s going to be used for the same purpose in five, six, ten different networks.

Tim Denton: Thank you.

Alain Durand: Alain Durand. I would like to answer Owen’s point. The place where 6to4 is done today is at the CPE, and they simply turn on some code, sometimes it’s a PC acting as a CPE or sometimes home gateway acting as a CPE. CPE means customer premises equipment, not router.

And that code, many of them have outcoded what is RFC 1918 and what is not, and they use this information to start 6to4. It would actually break 6to4.

Now, RFC 1918 is free spaces, one is ten /8s, 192.72.16 /12, and 192.168 /16.

Now, we can use any of that as space in between the CPE and the carrier grade NAT. There is no reason to use anything else. The only reason that is has worked so far is that it may conflict with whatever the customer had been using inside. Most of the CPEs use actually 192.168 or 10-dot-something. So if you overlap with a 172.16, is actually relatively small.

So I understand that people don’t necessarily want to tell their customer go renumber, but I believe it’s actually a smaller price to pay to get those customers to renumber internally than to ask for this that has the bad side effect of breaking a number of IETF protocols, 6to4 being one of them, but there are others.

Tim Denton: Thank you very much.

Leif Sawyer: Leif Sawyer, GCI Alaska. I’m in favor of this proposal. I see NAT 444 as a way to accelerate IPv6 uptick, because the problems that we’ll find in NAT 444 go away once we have a complete IPv6 transport.

So allowing this gives us greater impetus, I think.

Tim Denton: Thank you. We have a remote participant. And we’re patiently awaiting.

Scott Bradner: This is from Joe Maimon at CHL: Opposed to this proposal for many reasons, but for this conversation I would settle on that this is not ARIN’s role, and if ARIN was to get into operational engineering, there are lot of other things I think it should fix first.

I think any conservation effect intended by this proposal is meaningless without some teeth. I believe that the engineering challenges intended to be solved with this proposal can be solved in other ways without burdening the community in any way for creation of one-off, special-purpose allocations. Will probably not work as intended anyway and the wrong size for the job, to top it off.

Tim Denton: Thank you.

Chris Grundemann: Chris Grundemann, CableLabs, ARIN AC. I’m in support of this proposal. I believe it’s fairly obvious to me at least that carrier grade NAT of some flavor is going to be something that everyone has to deal with at some point, whether you’re deploying it in your network or your customers are talking to a device that’s deployed in a network with carrier grade NAT.

And that removing as many problems as we can with that is a much greater benefit to the community than the few folks who would get addresses out of this /10. I think it’s an obvious greater good. To the comments about this having global impacts and affecting other protocols or other devices, that’s only the case if you choose to deploy this.

And so each operator makes their own routing decisions. Just because ARIN sets aside a /10 for this purpose does not require you to use it. If you feel that 1918 space is available to you and better in your particular instance, then use it.

But there are a number of folks, a large number of folks, who that’s not the best option today. To the size issues, a /10 probably isn’t enough space for the biggest carriers, but it probably is enough space per carrier grade NAT device, but you’re only going to want to have so many devices behind each NAT, and /10 is probably adequate. It’s probably the smallest block that will fit this need, and thus probably the most appropriate to be set aside.

I guess that’s it. Thank you.

Tim Denton: Thank you very much.

Mike Joseph: Mike Joseph, Google. Concerning the points that have been raised about the 6to4 issues, I echo Alain’s point. In particular, I think that it is true that if you put this on the wire to the customer, they will have a device that will talk to it, whether it’s their home router or whether it’s their workstation that will attempt to use 6to4 and other technology assuming that it’s an external address.

And that presents us with only two choices. Either we’re telling CPE manufacturers and OS vendors to start encoding this address, this /10 block, as reserved space and nonpublic space, in which case ARIN is absolutely making demands globally, or we pretend that the problem doesn’t exist and let v6 adoption be further hindered.

And concerning the other point that has been raised about this deferring demand, more fundamentally, people suggest that this needs teeth somehow; that we need to compel providers to somehow adopt this should we move forward with this proposal. But we can’t. ARIN simply cannot be in the position of mandating operational configurations on networks. It’s just not going to happen.

It’s inappropriate for ARIN to do that. So the only concept of this deferring demand is if one or two providers, perhaps Cablevision, will decide to use this, but many of them will continue to make requests, and many of them have made requests for IP space. They already are asking for everything they can possibly justify.

Thank you.

Tim Denton: Go ahead, please.

Wes George: Wes George. Two comments. I think the 6to4 argument is actually one of the weaker ones against this. I agree that it’s something that is a consideration, but I think there’s two things that people need to know. One is that 6to4 still breaks with at least one of the alternative implementations to using shared space; that is, squatting on other non-1918 space.

We all agree that’s not a great idea, but it’s happening already, and it will continue to happen regardless of whether it’s recommended or not, because it is a viable way to do this if 1918 space isn’t acceptable for a number of reasons.

And so I think 6to4 at this point is kind of collateral damage of carrier grade NAT, not shared transition space. So I think it’s worthwhile to separate that thing out.

The other thing is IETF is currently discussing a draft that will deprecate 6to4. So it kind of ends up being a moot point, I think.

The other thing is to kind of echo what people have been saying about teeth and what this proposal is actually going to accomplish, the question I would ask is what prevents providers from continuing to go forward and ask for space, even if the provider eventually plans to use carrier grade NAT, I wouldn’t expect that they’re going to start using that until they can no longer get space from ARIN.

Even if they are hoping they don’t have to do it and continue asking for space, the thing that we seem to be scared of, which is that the big ISPs will continue to use up the remaining space, I don’t see how we’re preventing that with this proposal.

Yes, we’re giving them a way to potentially do the right thing, but I’m not convinced that’s actually going to happen.

And the following question is: What happens if someone comes forward today with a request for space to ARIN justified by the fact that they want to use it as an internal CGN pool? Is that something that staff will even approve today? And if so, is that not going to be something that they’re going to approve tomorrow and say, instead, you need to use this block? Are we actually going to enforce that if people are forthcoming with what they’re planning on using it for?

Tim Denton: Thank you.

Mr. Hughes.

Wesley George: Does someone want to answer that question?

Tim Denton: I don’t know. How many have you asked?

Wes George: Specifically the question regarding CGNs and ARIN staff.

John Curran: How many have we allocated for that purpose?

Wes George: I’m sorry, I couldn’t hear you.

Heather Schiller: The question is, do you permit people to request space for internal CGN pools today, and would you deny requests for that in the future if this policy is passed and how would you enforce that?

John Curran: Okay. So I’ll confirm with Leslie, but I believe an internal request – a request for space for CGN is a request for infrastructure and is equally valid to any other request.

So, Leslie – Leslie? – a request for space for CGN is right now we don’t treat – we would treat that as a valid request. If someone asked for IPv4 space for carrier grade NAT implementation, it’s still a valid request for space.

Leslie Nobile: I think –

John Curran: Yeah, there’s no reason not to. If this policy doesn’t state, then it would still be valid if someone said, I wanted to – I need space for transition purposes. If you specifically want to preclude that, you would want to be explicit in the proposal.

Internal infrastructure, this isn’t for a particular technology. We don’t necessarily have a way of ruling out technologies and saying this space has been assigned unless you tell us this space is for these particular technologies.

Wesley George: So I think that my recommendation is for those in support of this proposal, you need to be thinking about how you update the language to cover that problem.

John Curran: Can I just ask a question about that? For someone who comes back and says, yes, I see the allocation of a /10 but what I really need for this purpose is I really need a /9 because of what I’m doing, and /10 isn’t good enough, you would need to be very clear that not only is this the only block to be used, but it is big enough because we’ve told you it is.

Tim Denton: Mr. Hughes.

Aaron Hughes: Aaron Hughes, 6connect. There have been several comments about pushing vendors to change code to accommodate for this transitional space. And I wanted to remind the room that the goal is to get the vendors to implement native v6.

(Applause.)

NAT 444 is a technology that’s being used because we have to and because we cannot go to all of our customers and tell them they have to replace all of their devices, patch all their systems, upgrade operating systems, et cetera.

The idea – the goal is to get native v6 to the end and support v4 for devices that cannot be upgraded while they have to be, until they go away.

All vendors are going to have to make code changes. Period. Hopefully fully in support of going native v6 and hopefully at some point making v4 go away.

Lee Howard: I have to readjust the mic because the previous two speakers were taller.

Lee Howard, Time Warner Cable. I agree with Wes that 6to4 is on its way out. It’s broken. And this – and it will be broken regardless of this proposal.

I want to try to convince Wes that – I don’t expect ISPs to be applying for additional space for inside their CGN, because, as you just said, an ISP makes requests to ARIN for address space to number their customers. That’s what the space is for. And if some of that space is behind a NAT, it’s still your numbering customers.

I think what happens is not ARIN runs out faster, it’s that – because nobody’s going to deploy carrier grade NAT until they’re required to, until they can’t get more IPv4 space from ARIN.

So what an ISP has to do is stop assigning unique IPv4 space to customers sooner so they can reserve that space for inside their CGN. And of course outside their CGN.

The ramification of that to me is that we push NAT, we push CGN to consumers sooner than we otherwise would.

And potentially significantly sooner depending on how large any given ISP’s CGN would be. And I believe that CGN, that NAT 444 is bad for consumers because it breaks stuff.

And, as Leif said, that may in the grand scheme of things push IPv6 deployment faster because consumers will find that their stuff breaks and they have to go to their electronic store and replace it. But forcing consumers to replace their own electronics sooner is still – out of their normal replacement cycle is still bad for the consumer.

And we need to be thinking about what’s best for the people in our region who are the people who ultimately I think we all work for and should be worrying about. Thank you.

Alain Durand: He can say maybe we will deprecate 6to4 at some point. I would be all in favor for it. But in reality there’s millions of devices that have coded NAT. And ignoring those millions of devices is not a good stewardship of the Internet.

Tim Denton: Thank you.

Jason.

Jason Schiller: Jason Schiller, UUNET, Verizon. So my biggest concern about this policy is some confusion that I have about how these 2011-5 addresses could be used.

I see two possible use cases. In the first use case, those addresses are only used within the provider network. You’re basically creating a provider-only RFC 1918 address pool. The way those could be used, for example, could be to address provider-based large-scale NAT, what some people call carrier grade NAT, in a NAT 444 configuration.

In that case, the NAT 444 on the CPE could use RFC 1918 address space, and the carrier grade NAT space could use 2011-5 address space. That’s one use case.

When I initially read the proposal, that’s what I thought was intended, because there’s some language in here that says this – where is it? – it is to be shared by service providers for internal use. So I expected that it was not going on customer premise equipment.

The other use case is to use this to actually roll out NAT 444 to customer premise devices whether that’s stand-alone NAT 444 or in conjunction with carrier grade NAT 444.

In that case you’re putting the 2011-5 IP addresses on the wire to the CPE, and in that case it can break lots of things.

I am certainly not in favor of using the addresses in the latter case. The former case may be acceptable.

But I think we should be clear under this policy if both cases are supported or only the former case. And it’s not clear to me.

Can someone comment on that?

Owen DeLong: Owen DeLong, Hurricane Electric. As I understand the proposal when I discussed it with Chris Donley, the author, at the CableLabs summit in San Jose – by the way, this was written by a bunch of IPv6 proponents. So it really isn’t about extending v4’s useful life; it’s about dealing with reality.

The intent is that this sits on the outside of the customer’s NAT. So the customer is running RFC 1918 within their premise. Their outside address would be assigned out of this space and would go to a gateway address within this space that would be the carrier grade NAT.

Does that answer your question?

Jason Schiller: I think so. Let me make sure I understood it. This 2011-5 address would sit on the customer premise equipment when?

Owen DeLong: So if you think of NAT 444, this address space would be the middle 4.

Jason Schiller: So the address space would sit on the large-scale NAT device in the provider equipment only?

Owen DeLong: It would sit on both. It would be the address space that the large-scale provider NAT internal side uses to communicate with the customer premise external side.

Jason Schiller: So it would be on the customer premise WAN?

Owen DeLong: Yes.

Jason Schiller: Okay. Thank you. So both cases is the answer.

Tim Denton: We have eight minutes more of discussion before moving to a vote.

Alain Durand: In discussion with Lee, I just wanted to bring this up. The part I’m really opposed to is creating an extension of RFC 1918 for customer devices, putting this address here on the one side of the CPE, because, as I mentioned, there are millions and millions of devices who have outcoded this space.

If that was to be used for something else inside a service provider, it doesn’t communicate with anything on the outside and that no actual customer electronic box would ever see, I will have much less of an objection.

Tim Denton: Thank you.

Wesley George: Wes George of Sprint.

Tim Denton: You two, and then I’ll cut off discussion.

Wesley George: I think we need to be really careful of the slippery slope of legislating how this is going to be used and not used.

It sounds to me, and I’m feeling better about it, because it sounds like we were talking about both cases, but I know that the application within our network actually would be a NAT 44 in most cases, not a NAT 444.

This is where we would have to transition away from giving mobile devices a routable address and have to move into a situation where we’re giving mobile devices a non-routable address and putting a NAT in between it.

If you are saying that this space is not approved for that use, that means that it has an even narrower set of solutions that it’s actually applicable to, which makes it all the more useless.

Tim Denton: Thank you.

Mike Joseph: Mike Joseph, Google. John Curran indicated earlier if we want ARIN to mandate the use of this space and exclude it as – just exclude uses covered by this space is allowable justification for other allocations, and I think that would both be incredibly out of scope for what’s been proposed here today. But also because I think that that’s just totally inappropriate for ARIN to do.

And I would strongly oppose that. I know some of the commenters who are in favor of this proposal have suggested that we would need to add that kind of teeth to it, but I think it’s wholly inappropriate for ARIN to be in the business of mandating the particular configurations of selection of address space for their various purposes.

And, moreover, ISPs will already have their address space; might as well let them use what they already have.

John Curran: Can I answer a question about that?

Tim Denton: Was it a question?

John Curran: You said two different things, and I want to know which one you actually meant.

You implied that ARIN should not be telling ISPs how to do certain – run their network, but you also said – let me try to rephrase.

ARIN wouldn’t be telling ISPs how to run their network. What they’d be saying is you would not get additional IPv4 space if the purpose was something that the community said there is a NAT shared pool space for.

Mike Joseph: Right.

John Curran: Obviously ISPs can run their network any way they want, but if they want additional space and you folks say it shouldn’t be used for this purpose, we’re going to enforce that.

Mike Joseph: Sure. But what we’d be saying in that circumstance is that – and I’m not criticizing staff; I’m criticizing the potential policy, which hasn’t been brought, so we should be careful about adding it to this one.

But what I would say is we are mandating particular designs for ISPs because we’re fixing up – we’re specifying a fixed size of a /10 which would limit carriers’ ability to deploy NAT pools as they see fit for technical reasons. We don’t see it elsewhere.

John Curran: So you’d like to make sure that address space is continually still available for this purpose and not just that they’re forced to use this particular allocation.

Mike Joseph: At this particular size.

Tim Denton: We have a remote participant.

Scott Leibrand: Kevin Oberman from ESnet says: It should be understood that the address is on the ISP side of the CPE and should need no special treatment.

He’s undecided.

Tim Denton: Okay. Mr. DeLong.

Owen DeLong: To rebut very quickly what Mr. Joseph said, some of the very largest MSOs got together and kind of came to the – they’d rather have a /8, but they came to the agreement they could make a /10 work in their environments.

And so the inherent belief in the policy is that the very largest of the providers can make a /10 work, probably some of these smaller.

I don’t think the intent is to preclude Sprint’s use case that Mr. George expressed. I think that the intent is to be as encompassing as possible to the different use cases for large-scale NAT that are out there. I guess that means Jason’s definition of both cases is certainly true. The purpose envisioned by the authors was the intermediate space in NAT 44, the 4 in the middle.

Tim Denton: Thank you.

Now it’s time to take the temperature of the room. Those in favor of the proposition being advanced to the Advisory Council, 2011-5, would you please signify your approval of this being sent to the AC by raising your hands.

You can lower your hands. There’s a few moments for the remote participants to vote. Mary K., do you want to – the remote participants – all right.

I’ll have the against. Don’t worry. So then those against having this proposal sent to the Advisory Council for their consideration, would they raise their hands.

You can’t speak to the proposition, Cathy. Can it wait for a moment?

Cathy Aronson: This is Cathy Aronson. Can you explain what it means by being sent to the Advisory Council? Because this is already on our docket in a Draft Policy. So we were just voting to send it to the Advisory Council? I don’t understand that.

John Curran: I think you meant –

Tim Denton: Probably because I’ve stated it wrong.

Those in favor of 2011-5. There’s a total number of people in the meeting room and remote of 116. In favor of it were 30 and against it were 15.

There we are. That’s it. Thank you very much.

John Curran: Okay. Wonderful. It’s getting to be that time. It’s high noon, and we’re going to break for lunch. We have an hour and a half for lunch. I hope everyone has a good opportunity to enjoy themselves, maybe walk out in the sunshine briefly, and then we’ll bring you back into the cave here at 1:30 to resume policy discussions.

So I’ll see everyone back here at 1:30. Remember, there’s lunch topic tables at the meetings. And find a table where people are discussing issues that you’re interested in, and that’s about it. Begin thinking about your surveys. We have surveys that will need to be filled out. You need to take your valuables with you. There’s no security in this room.

Thank you very much. See you at 1:30.

(Lunch break from 12:00 to 1:30.)

John Curran: Okay. I’d like to get started. We have several reports in the afternoon followed by Open Policy Hour and open microphone.

The first presentation I want to do, I want to finish up the RIR Updates with an update from AFRINIC.

And Mark Elkins – is Mark here? Yes. That’s wonderful. Come on up, Mark.

RIR Update - AFRINIC

Mark Elkins: Good afternoon, everybody. I am Mark Elkins. I’m a Board member. I’m the only AFRINIC representative at the meeting today. And these are not my slides. They are my slides; I didn’t make them. These slides were presented at Hong Kong a month or so ago. So it’s full of stats.

So we have 21 staff members at the moment. The thing about staff members is half of them, literally half of them, have joined very, very recently. So it’s a very fresh bunch.

Budget of 2.8 million. I think it’s in red because at the time of the presentation in Hong Kong, it hadn’t been ratified by the Board, which it has been now.

Just over eight million IP addresses allocated in 2010, and we’re doing well with other things as well.

New membership is still climbing. I guess that’s kind of different to this particular region. And we have our two annual policy meetings: We had one in November in Johannesburg, and we’ll talk about the next one coming up soon.

We do travel a lot. We do train a lot. The last training session was a couple of weeks ago. And in Ghana, I believe, or there’s one coming up in Ghana just now. And more of that later.

Policies under discussion. Basically the same sort of policies as we have here. The process is more or less the same.

The biggest difference to me from a learning point of view is our PDP leadership group is comprised of two people where you have 15 here.

Some more pretty pictures. Some more stats. Everything is growing. I don’t think there’s been a fright with the Miami announcement like there has been in other areas.

IPv6. The spiderweb is slightly interesting. Again, South Africa seems to consume most of the resources. It’s unfortunate, but that’s simply how it seems to be going.

I was told that if I got this presentation out of the way very quickly we could all go to the beach. So here I am almost towards the end.

We do have a beautiful new office. The offices really are rather beautiful now. Training rooms, et cetera, et cetera. Very nice.

And the next AFRINIC meeting will be in Dar es Salaam in Tanzania. Why Dar es Salaam? Why would you want to go to Dar es Salaam? If there’s any Queen fans, you will remember that Freddie Mercury was born on that island Zanzibar. It’s very, very close. The scuba diving there is absolutely fantastic. So I would expect to see some scuba divers there, perhaps.

But, otherwise, come along for the meeting. You are warmly invited, and it will be warm. Just like here. Thank you very much.

John Curran: Any questions?

(Applause.)

John Curran: Moving right along, we have an update on ARIN Online, new features into this. Andy Newton, come on up and give the new features of ARIN Online.

ARIN Online: New Features

Andy Newton: Hi. I’m Andy Newton. I’m the chief engineer at ARIN. Part of my responsibilities are to oversee the software development processes that affect our registration system, and the systems architecture that go along with that.

We’ve talked in the past couple of meetings about a major fundamental shift in our data model, moving away from putting nameservers on networks and more closely mirroring how the DNS actually works. And the reason for doing that is to support things like DNSSEC.

That required a lot of software to be rewritten or completely replaced. And we’ve been doing that over time, and we have – on March 19th we did a very, very major software release which kind of was the culmination of all this work over the years.

And as such, that release caused a lot of new features and a lot of changes in how our systems operate.

We also made a couple of small releases along the way. But all these changes are since the last time ARIN had a meeting. So we thought we’d go over them.

The first one is Bulk Whois. Previously we moved Bulk Whois away from being accessed via FTP to using a RESTful Web service, and we went ahead and modified that, enhanced it a bit, so if someone wants to get a specific type of data out of the Bulk Whois they don’t have to go and download the entire huge file.

The same is true if they want in a particular format. You still get it in the large zip file but now you can target what you want.

For Port 43 and Whois-RWS, we enhanced the CIDR support. The CIDR was there on the RESTful side all along. When we did that, we put in a CIDR exact match query semantics on port 43. However, that wasn’t very useful in a lot of situations.

So we went back and redid it and we now support the less and more query semantics for CIDR on Port 43. That should be more useful.

In addition we inadvertently had broken a couple of things we didn’t notice immediately, such as being able to do the CIDR queries in the search box on the Web and the same thing for v6 queries. So we’ve fixed that as well.

On top of that, for people who were coming in web-side who were looking up resources, they would get redirected to the RESTful system and would take advantage of the nice features there.

But if you’re looking up an org or a net or an ASN, you wouldn’t see some of the related information such as you would with Port 43. So we added the resource and now so people who were coming in via the web GUI can see all that information in one page.

And because we changed the delegation model, via Port 43 and via the RESTful service you can now query directly for delegation information.

As Leslie touched on yesterday, we did some work around – more work around POC validation. If you log into the website and you’re a user linked to a POC that’s invalid, you’re going to find that you can’t do a whole lot of stuff until you make that POC valid again.

And, in addition, for ORG recovery, we changed the way some of the email gets sent out. It’s a lot more reasonable and sane.

On Sunday, Jon Worley did a tutorial on the new ARIN Online system and he walked through a lot of the enhancements we’ve made, one of which you can now request and you can now manage your networks and ASNs online.

You can now do that online, and, in addition, you can also manage your nameservers online. One of the things we’ve got here, not only can you put your name server information in, you can also add a DS record. And this will help you do DNSSEC in the reverse.

John Curran touched on the Specified Transfer Listing Service yesterday. One of the things we’ve done in the software on the website is there’s now a third actor called the Facilitator. We had Needers and Listers before. And the way it worked is the Needers could see the Listers and the Listers could see the Needers. We added a third actor called the Facilitator. And the Facilitator’s job is to put the Needers and Listers together.

But we also wanted to change the way the access model works, so now Needers, Listers, and Facilitators can all see each other.

And as part of the March 19th release, one of the things we had to do is we had to basically had to do a forklift upgrade on our provisioning system. When we did that, we added the RESTful provisioning service. Tim Christensen did a tutorial on this on Sunday.

There’s the link if you want to go get all the information if you are a programmer or have programmers work for you, you can point them to the link and there’s all the documentation on how to get your providing systems to talk to us.

We also have an OT&E environment. What this allows people to do is when they’re writing their provisioning software and want to talk to us, as opposed to playing around with live data, you can come in and you can use the OT&E environment to kind of vet your software and make sure it’s doing what you think it is, without really messing up your data.

We do keep that environment ACLed, so if you want to use it, you need to send us email, let us know where you’re coming from and we’ll grant you permission to it.

On top of that, because we have this new provisioning system, we now require API keys in the version 4 and the version 5 templates, but the benefit to that is you can now, when you submit these templates to the API key, if there’s an actionable request that requires ticketing, you can log into the website to see the status of your ticket.

V3 templates in the past we deprecated those and now they’re no longer accepted.

Those are all the things that changed. There’s quite a lot. I know I covered it real fast. It’s quite a lot of stuff there. Doesn’t mean that we’re now sitting idle. There’s a whole lot of work we’re still doing. So I’m going to give you a preview, talk about some of the things we’re working on.

For RPKI, we started development of this last year. The RIPE NCC graciously gave us some software and it was very beneficial, kind of helped bootstrap our whole processes into this.

Unfortunately, we identified some vulnerabilities and liabilities specific to ARIN. And it caused us to rethink the HSN that we were using, the hardware security module. We’re no longer able to use the RIPE NCC software to the extent we thought we had to and we have to program around the HSM. But we’re still working on that.

For online billing we have a billing system from a third party, specifically because finance people and auditors really don’t like employees to be messing around with the finance systems.

We want to integrate that into ARIN Online so when you come in to ARIN Online you can see your invoices and your billing data and upgrade your billing contacts. Well, in order to get to that point, just like we have people talk to us via web services, we have to talk to the billing system via web service, and we had to upgrade that software.

So that’s done now. The billing system has been upgraded and now we’re beginning to work on being able to allow people to access their billing information via ARIN Online.

We have an Internet routing registry, which reuses the RIPE NCC software and we’re making a couple of changes to that as we speak. One of the things we’re doing is we’re adding PGP and Crypt-PW authentication. And we’re re-enabling some of the notifications that we had previously disabled before.

One of the things you’ll notice is a side benefit of the new authentication systems in the IRR is that we’re going to map our maintainers more closely to ARIN orgs, and this is kind of the way – more like the way the RIPE NCC runs their software. And, more specifically, if you go read the RFCs, it makes a lot more sense that we’re now mapping to what the RFCs say should be done.

And, finally, the RESTful provisioning system. Like I said, on March 19th we released this. It was kind of version 1.0 and there’s a couple of things we’re going to continue to add on to that, the first being a programmatic way for people to modify their nameservers and DS records, and the second one, as we’re finding out, some people need a method for discovering what resources they hold in the ARIN registration system. They need a programmatic way of doing that. So we’ll be adding methods for them to do that as well.

That’s really all I have. I do want to remind people there’s the arin-tech-discuss mailing list. If I hadn’t been absentminded, I could have put it on the slide. If you have a question and it doesn’t get answered here, you can always send it to that mailing list, and the engineering and RSD staff monitor it. Or perhaps if you go and look in the archives, the question has already been answered.

John Curran: Any questions?

Marty Hannigan: Marty Hannigan. So how often is the public STLS summary report updated? I notice that it looks like the last time it was updated was November 2010.

John Curran: Right now the STLS service is just getting started, so we don’t have a regular schedule, but we –

Marty Hannigan: So there’s been no activity for six months? Basically it’s –

John Curran: No, no. So what I’m saying is that because we just changed the access method and the automation of it, it hasn’t been updated. It will be updated. We’ll try to get that out very shortly, like in the next week.

But we’ve got to go back and contact everyone who was in it because we changed the access model. We need people to know they can be seen by anyone on the listing service. So we sort of had to do a restart.

Marty Hannigan: So it’s not accurate, but it will be accurate?

John Curran: Correct.

Leslie Nobile: I think Marty might be talking about the public report that we’re supposed to list the STLS participants and we update it as we add to it. And thus far there’s only one person that’s actually qualified, I believe one as a Lister, and we have one new facilitator that’s going to be added. As you add them, they get updated.

Martin Hannigan: That is what I said, the public STLS summary. Thank you.

John Curran: Center mic.

Sandy Murphy: Sandy Murphy, SPARTA. I hope this is the right venue to ask the question. Yesterday there was a lot of discussion about the transfer and the listing service is part of that.

I was wondering about your consideration of transfers and how they will relate to the RPKI certificates, and if you have a process in mind for that.

John Curran: Now we have a RPKI presentation coming up. Why don’t we take it at the end of that in about 15 minutes. It’s a great question, though, because obviously RPKI involves interesting chains that need to be swung when that happens.

Thank you, everyone.

(Applause.)

John Curran: Speaking of which, next presentation up would be our Resource Certification presentation with Mark Kosters.

Resource Certification: RPKI

Mark Kosters: All right. How many of you guys are really interested in this? Okay. About half the room. And the other half, are you all sleeping?

Tim Denton: You can shorten your speech by half.

Owen DeLong: We’re bringing in the geese.

Mark Kosters: You’re bringing in the geese? I have a story about that, but I’m going to bring it up tomorrow.

So, first of all, I must say I have no tasteless pictures in this presentation.

Owen DeLong: That’s it. I’m leaving.

Mark Kosters: So we’ll go ahead and get started on this, because this is actually a moving target, and what we want to do is give you an update.

I’m going to talk a little bit about what engineering is doing with respect to RPKI. John’s going to follow me and actually talk from a Board perspective.

And we’ll go on from there. So we’ve had this pilot since 2009. Who has actually participated in this pilot? Oh, that’s really cool.

Actually, I encourage you, given that we don’t have anything in production right now, ARIN, to that matter, to go ahead and play with this so you can actually see what’s going on.

One of the things I’m working on inside is actually plugging in the output of our pilot within other sort of repository aggregators that are out there.

So this is actually an interesting thing to do. There’s been a number of people that have been playing with this. And just because I like to be a little competitive, and unfortunately Geoff Huston’s not here – oh, there he is, okay – we have 45 organizations participating, and LACNIC has this really cool heat map stuff that they put out.

And actually we’re number two in terms of actually usage of the system. So I look forward to APNIC actually passing us by off our pilot.

Now, I can’t vouch for the validity of some of this, but at least it’s there, and people are actually using it.

And I encourage you to do this as well. Please join the pilot, and I will get back to you and give you some – your resources, will make a snapshot off of our database and you can go ahead and play with this.

All right? Sound good? Okay. So here’s what we were planning on doing initially. We were going to do a tight coupling with our existing ARIN Online system.

So it involves a lot of sort of Java-based lingo here, database persistence and RPKI engine and an HSM to actually do the secure storage of your keys.

One of the things we would do is every time you would get an allocation, we’d recut your certificate that’s associated with your resources and send that out to you.

So that was our initial goal. And we were actually ready to go with this on January 1st, 2011, with a hosted model and were going to follow with a delegated model which allows you to essentially have your own certificate authority and you can run these things locally and we would communicate with you with a protocol called up/down.

And we were going to use RIPE’s code, which they graciously allowed us to use, which Andy talked about earlier, with a few tweaks, to talk to a Sun SCA 6,000, which was our HSM, initially. And everything at that point is Java, JBoss, Hibernate, and all these other good things which ARIN Online uses today.

So when I talked about this at the last meeting, one of the things that was put into the presentation was this text here.

So we were going to sign the cert directly assigned allocated resources, nothing else actually matters, we were going to – all these things are actually under review, and they are still under review by the Board of Trustees along with ARIN’s general counsel, looking at the risks associated with all this.

One of the things we’re doing with this is actually letting you know what’s going on and so that you have a better awareness of the things that we’re struggling with.

So one of the things that came out of that last ARIN’s meeting is that we had some new requirements. And I’m kind of like Mikey apparently within ARIN, because if there’s anything bad that can be done, I’m usually the volunteer that will be willing to try it.

So John said, okay, we gotta make sure that we can’t allow evil Mark to actually manipulate the repository and mess up with your resources, because it could affect routing.

And there were also some other liabilities we wanted to look at as well. So there were two things that came out of this as a result. One is everything that we log through, all the signing activities are logged and you can actually – you can actually see that there’s no way that an ARIN employee – or actually you would have multiple ARIN employees to actually make this happen – would not be able to change the logging at all.

So I can’t go in there, mess with your certificate, remove that log entry and say: Oh, that’s the way it’s always been, sorry, I don’t see anything in the logs, so you’re good to go there.

The other thing we put in that I’m going to discuss here in a little bit is that you, aside from just logging in and having a user ID and password, you actually have to have a secret key to actually do ROA generation. I’ll get into that in a minute.

So what we have here is that there’s some really cool features that are coming out. One of them is you can actually do in-browser ROA request signing via AJAX. It’s all really cool and it’s something that’s almost effortless. And I’ll have some screen shots that actually shows this.

You can see that there are minor changes that we needed for a database to make this happen. Given that we had this big, big forklift release that Andy had just talked about, we now have a lot more flexibility in our system to make changes much like we need to do for RPKI.

The engine itself is stuff that we originally thought we could take from RIPE, but it turns out we had to rewrite almost all of it.

And to do so, we had to do some custom programming on IBM 4764, which allows you to do online signing on HSM with additional tweaks. So it’s actually really cool crypto stuff that we’re doing. It’s really making the engineers really happy working on this, and they tell me things I don’t understand.

So here we go. We’re going to go ahead and create a ROA. This is what it’s going to look like. When you log into ARIN Online, you go ahead and select manager resources and you say, okay, now I want to be part of this RPKI system and I want to have a hosted sort of activity going on, where ARIN will manage these things for me.

So you can see here there’s this yellow thing and it says keynote loaded. Can you all see that?

I can see it. So here you have something that maybe you can’t see. And that’s actually you go ahead and you select your private key. Okay? And then it says, oh, my goodness, you’ve got this private key and you just loaded it in, and it’s now loaded into the application.

Then you go say, okay, I want to create a ROA and it has all these wonderful attributes associated with it. And then what it does is it signs it through the HSM and sends it to our provisioning system on the back side.

The reason why this is not real time is the HSM can be slow, and we didn’t want you to be waiting there for a while. So what you would receive is a success message in your message center saying that, hey, this ROA has been successfully created and you can keep going on your way.

And here you can see that the submission process is actually done. So now as far as the community goes, four of the five RIRs are now in production. They have at least hosted CAs, and two of the four have up/downs so ISPs actually can run their own CAs if they so wish.

Geoff, is anyone doing up/down with you guys?

Geoff Huston: No.

Mark Kosters: Do you know if AFRINIC, if they’re doing up/down?

Geoff Huston: It’s our code, so they have the capability of doing it, yes.

Mark Kosters: But you don’t know if they’re actually doing it?

Geoff Huston: I don’t believe they are.

Mark Kosters: So I did not know that, and it was not a plant.

So major routing vendors are behind us, the C and J router vendors that I think you all know and love, they actually have code that actually does RPKI sort of validation. And there’s actually – at the IETF there’s an exciting announcement that there’s a public domain routing code support coming in as well.

John Curran: Back up. So Sandra asked a question with regards to transfers. And that applies both within ARIN and then also potentially transfers into RIR.

Can you talk a little bit about what’s happening at the RIRs and working on the architecture to allow that?

Mark Kosters: So transfers are, frankly, very ugly, and there’s a lot of complications with this. And within the regional registries, we’re actually working on a model to make transfers happen. That has not come to fruition yet, but we hope to take care of this within the next year.

So given that there’s really no transfers going on within the regional registries right now, I think we’re safe for a little bit, but we do need to deal with this, but it is thorny. It’s not a simplistic thing to do.

John Curran: To say a little more, the regional Internet registries have looked at two, three, maybe four proposals for how to build trust anchor trees and how to swing resources from one to the other, which is what’s necessary during a transfer. And there are different implications of each. I think have we converged on a rough architecture.

Mark Kosters: We’ve converged on a rough architecture, but it’s just specifics we’re going through now.

John Curran: And then at the point in time when we know that, we’ll get that documented so people understand how a transfer would work and what the actual keys would look like as a result.

Does that address your question? So working on it. That’s an example of the work that’s taken by the engineering coordination group of the NRO, which is the sort of RIR staff and engineering in each of the five RIRs, is to coordinate work like that and come up with a proposal for everyone else to read.

Mark Kosters: So we hope to have a hosted CA with these new modifications I talked about with the HSM, be done and ready for rollout in May at the earliest. As soon as RIPE NCC finishes their up/down code, we hope to prolong that and actually put that in our system as well.

And that’s looking like it’s going to be made available at the upcoming RIPE meeting.

So actually they’re doing some very cool things within RIPE on dealing with this. And we saw a little bit of a preview of this at the IETF a week and a half ago.

So we’re looking forward to actually seeing this code and actually implementing it ourselves.

And the last part is what John’s going to talk about.

John Curran: So within ARIN, we actually went to the Board and went and reviewed the risk model and came back, got feedback that’s led to many of the engineering changes you’ve seen.

We actually are putting together a full package for the Board that explains the risk model, the mitigation steps, what liability ARIN could have for both hosted and up/down.

The Board expressed its commitment to the fact that there’s a support for the concept of RPKI in the ARIN region, but obviously we can’t comment on particular services until we’ve done the whole package, including the terms of service, the liability involved.

That’s something that we’re going to bring in front of the Board in the May time frame with the hope that at the end of the second quarter or early third quarter we could roll out one or both services.

Obviously the up/down protocol is sort of essential, because if ARIN doesn’t support that, then you can’t have a tree that signs the resources in this region at all. And that’s well understood.

Hosted is different. Hosted is something that any organization could build their own RPKI system and run their own CA and do their own certificates. The convenience factor is why ARIN’s looking at it, but the liability that goes along with that is significant, if something were to go wrong.

So both of these are on the docket for May consideration by the Board. We have a lot of things on our plate right now, but I’m going to write this up and I’m optimistic.

One of the things that we need is to understand, we, the organization and the Board, is interest in these services, both hosted and up/down RPKI. It was interesting, Mark showed 45 organizations using it but we didn’t see any hands in the room.

And I’m trying to reconcile that. I’m interested in knowing who is interested in using these services in the ARIN region, because obviously we’ve got things that we should be doing that are higher priority if no one here actually cares about them.

So that would be a good thing for people to come and express at the microphones, if you think you’re going to make use of these services.

Marty Hannigan: Marty Hannigan from Akamai. I think we’d be interested in utilizing something like this, but I don’t think we have nearly enough information.

I would suggest that perhaps an interim step before proceeding as you said and potentially making major investments and going forward would be to have a public comments period with a little bit more detail information like why should we trust the RIRs and things like that.

John Curran: Question on that. I think that’s worthwhile. In terms of the service, have you used the public trial at all? Because that’s been out there for people to get their hands on.

Marty Hannigan: No.

John Curran: Anybody else in the room using RPKI services?

Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. We’ve got a couple of people using the public trial. I’m not personally involved in that effort. But we’re very interested in the up/down service, not all that interested in hosted.

John Curran: Okay.

Jason Schiller: Jason Schiller, UUNET, Verizon. We are interested in using this service and are interested in the up/down portion and hope to have the cycles to play with it later this year.

John Curran: Thank you.

Wesley George: Wes George, Sprint. What he said.

John Curran: Thank you. I feel like it’s a little confession circle as people get up.

Lee Howard: Lee Howard, Time Warner Cable. What they said.

Tim Christensen: Tim Christensen with ARIN staff. I’m monitoring the remote participation room, and Kevin Oberman from ESnet has also expressed interest.

John Curran: Okay. Thank you.

Chris Morrow: Chris Morrow from Google. I think we are interested in not necessarily the hosted part but the up/down protocol. And one of our folks has been participating in the bake-off work with the software, not necessarily the ARIN portion of it, though.

John Curran: Okay. Thank you.

Microphones remain open.

Unidentified Speaker: John, I kind of like to hear the confessions.

John Curran: People who want to see me anonymously afterwards, we can find a little way for you to talk to me through our grid or something, say: I’m an RPKI user and I –

Wesley George: Hi. My name is Wes, and I’m an RPKI user. No.

Mark Kosters: Can I start you with a ten-step program?

Wesley George: So I sent a message out to PPML a week or so ago about some of the sort of security aspects about this that are different now in terms of its impact to the routing. In your comments it sounds like you’re already thinking along those lines. I think the feedback I would give is beyond what ARIN needs to do, in order to protect your end, I think there’s probably some gaps in terms of what you expect from your members, how they need to handle this.

For a lot of folks that are implementing this, this is new.

The folks that are testing it, the expectation is they have kind of been involved in something about this, but as it becomes more mainstream, implementing this in a way that is – that actually is trustworthy and you can believe the veracity of the infrastructure.

It either requires some familiarity with how you manage an RPKI and what are the best practices for that, and how do you ensure that things aren’t compromised.

But for folks that aren’t familiar with that, there’s a whole series of considerations in terms of making sure they’re doing the right thing so this is actually a trustworthy model, that above and beyond whatever ARIN has to do in order to verify that I am me and I am authorized to do what I’m authorized to do, there’s sort of the back end of this, how do you manage it within the company for your individual users; that while you can’t require any specific thing because that’s sort of beyond your area of influence, what you can have is a combination of education at places like NANOG or the other NOGs, and online training or something of that nature. You guys have been pretty good about that kind of communication with other things.

And then also probably some just documentation this is the best practice of how – the things you need to be concerned about as you implement this in your network.

I’d encourage you to think along those lines. I brought the conversation up in CIDR, the working group as well, with the expectation that IETF may be able to provide guidance there. It’s not an ARIN-specific problem; it’s an RIR problem. It’s variations on a theme in all the different regions, but it’s something that I think we all sort of need to be thinking about as far as how we manage that going forward.

John Curran: Okay. Let me ask a quick question about that. So regarding outreach and RPKI, ARIN’s naturally hesitant about telling the service provider community this is RPKI and you should be using it.

Now, the reason for that is because to some extent we like the bus to be the other way around. We like the service provider community telling ARIN: Implement this, this would be helpful.

Wesley George: I don’t think I’m recommending this is RPKI, you should use it. What I’m more recommending is the outreach is in the form of this is RPKI and if you’re interested in using it, these are some things you need to think about.

That’s more – it’s sort of here’s some things we’ve learned in practical application. Because it sounds like you guys, as you’ve gone through your application, you’re realize, oh, hey, there’s a whole bunch of things we’ve got to do.

So get into those details and relate it to if you’re interested in RPKI, here are the things you need to be worried about. I’m not saying go sell it. Hopefully that clarifies.

John Curran: But my question is putting Mark or Andy on the road to a NANOG meeting or a LRSA meeting or a peering meeting somewhere where they can talk about RPKI and here’s some issues, is that what people think we should be doing? Because there’s expense involved, obviously, and we don’t want to be the ones saying learn about RPKI, unless you folks want us to advocate that.

Wesley George: Just to answer that personally, I think it would make sense to do it in coordination with some of the folks that are working on this in CIDR. Because my understanding is that they got some of the same feedback, which is why Randy Bush and Rob Austein were here, I understand, on Sunday, to provide an overview and a tutorial was there were a number of folks that said you need to be a little clearer and explain this to people, how it works, what it does, what it doesn’t do.

So it may be one of those things where it just requires a little bit more direct coordination with that group of folks to make sure that it’s covered.

I’m not necessarily saying ARIN has to single-handedly shoulder that load.

John Curran: Good to know. Anybody wants to make comments about ARIN’s RPKI initiatives?

Sandy Murphy: Sandy Murphy, SPARTA. The previous comment or questions that I asked about transfer policy and how it was – the plans for how you were going to do that and certification came from a motivation of being co-chair of the CIDR working group in IETF, because it’s not something we’re looking at yet.

I did note that in your presentation you’re going to be doing certificates for people with direct allocations and assignments, and you’re considering what the options are for what you might do for the sub allocations.

There’s a possibility that transfer would occur, not at the RIR level but somewhere down.

So if your transfer process could be shared, there’s a possibility that we may want to consider it in the working group.

John Curran: Makes good sense. I think at a minimum the community is entitled to know whatever process the RIRs want to use and it should be documented clearly for everyone. The question is the feedback loop, does that go through rooms like this or the IETF or both. But I think it has to be documented no matter what we do.

Robert Seastrom: We have a comment by Kevin Oberman from ESnet. Thinks it would be proper to do a road show. Not only are they interested in up and down, but he believes they road show this is RPKI and this is how you might – why you might want to use it would be a good thing.

John Curran: Good to know.

Last chance for comments on RPKI. This has been very helpful.

Microphones are closing.

Go ahead, last speaker.

Jason Schiller: Jason Schiller, UUNET, Verizon. I think if you do a road show or a micro site or a FAQ or whatever documentation you put together, I think it would be important to also talk about the legal issues that you guys grappled with and what decisions and tradeoffs you guys made, because similar legal decisions with apply to people further down in the tree, and I’m not sure people have thought that through quite yet.

So in addition to talking about the technical what is RPKI and how does it work, certainly a primer on the thorny legal issues and your advice and lessons learned there would be useful.

John Curran: Yeah. I hear that and I support it in general. ARIN tries to avoid giving legal advice to other entities. But to the extent that there’s general sharing about potential risks, I think that’s something we can certainly do.

Okay. Thanks very much.

Thank you, Mark.

(Applause.)

Moving along, we now have the PDP Committee Report. I see Lee. People don’t know this, but Lee, even though he did not end up on the Board, we still kept tasking him, and he was Shanghaied, slash, volunteered into running the Policy Development Process Committee.

(Applause.)

PDP Committee Report

Lee Howard: Thanks. Here I am again. We have this Policy Development Process Committee. We have seven members. I’m not going to introduce them because I’ve done it already.

I had hoped to bring you a series of documents at this meeting and say here’s our output, what do you think. Unfortunately, we have seven members who are busy people and have many other obligations. And we have been going through cycles of updating documents, talking about what we want to do and then reviewing them, editing, coming back and reviewing them again. And scheduling meetings after each document cycle has been slow. So we’re not there yet, and I apologize for that.

However, we do have as a basic framework. We intend to bring three documents. One being – second bullet – in order to fix that, I’m trying to schedule regular weekly meetings so that the death march of progress will continue until we actually have documents to bring to the community.

Those documents are probably going to be framework of three documents: One that’s basic goals and definitions; one that is the actual process description; and a third one that is the petition process so that we have a description that is not interrupting the process description for where all the petition points can be.

And we also, in the process of doing this review, came up with some recommendations for the Advisory Council. Some thoughts on how – let me get into that in a little bit more detail.

Part one, goals and definitions document. And it’s going to include things like the purpose of having a policy development process, and what the – some definitions for what some terms that are commonly used in the PDP, what scope is, whether something in the policy or is operational; general principles, like clarity, conciseness, things like that; and then what are the criteria for policy changes, what needs to happen in order to enter that process.

Here’s a general graphic, because text is boring. Unfortunately, text is small. So I’ll read this to you. This is going to look fairly familiar. This is not a radical overhaul of the policy development process. In general, the direction we’re headed is there will be a Policy Proposal that gets an initial evaluation and then gets discussed by the community.

Following that discussion, or as part of that discussion, there will be a public policy meeting which may send the proposal back for more discussion and more development and come back to a meeting or it may go through discussion and development after a meeting and then go to last call. The details there are still being worked out.

Once we’ve had community discussion there may be more review needed, more edits. It might go back to more development and discussion and come back to the community.

In any case the community gets to see the policy proposed before it becomes final adopted policy.

And once there’s been a last call saying this is what we’re about to adopt, please confirm this is what you want, then the Advisory Council could recommend adoption and the Board could adopt the policy for staff to implement.

So this is essentially the process we have now. Not many changes here. There will be some. I would expect some changes, because that’s sort of why we kicked off the process in the first place, and I’ll come back to a little bit more on that.

There will be a petition process much like there is now. The documents are going to describe when petitions start and when they end, and basically it’s whenever there’s something that someone might object there will be an opportunity to object. There will be descriptions of what can be petitioned and what is out of bounds for a petition. You can’t say you don’t like the accent of the person who proposed – who described the policy at the meeting. That’s not fair.

What the criteria are for the success, what does did it mean to say a petition was sustained or upheld, and then if a petition is in fact upheld, is supported by the community, then what happens to the policy next? Or what happens to the proposal next? So specific details will be forthcoming once we have them finalized.

We identified as part of our original charter a series of problems that needed to be addressed, a reason why we needed to look at the policy development process.

And sort of top of the list was it’s hard to understand the policy development process. It’s complicated. It takes too long, and we do still get proposals that turn out aren’t really policy proposals.

We have some communication problems. There have been at times lots of policy proposals, and what are we using – what are we using the various parts of this process for. Such as at these meetings when you show your hand, are you voting? Are you voting on a motion, a resolution? Is it a straw poll, a sense of the community? What exactly does that mean and what are the ramifications of that.

As we looked at each of these, we kind of said some of these things aren’t really policy development process stuff. They don’t need to be codified into a formal procedure, but we do need to talk about them a little bit more and come up with more operational guidelines in the way we do things, not in a formal prescriptive way, but giving ourselves some room to make good decisions.

That’s why here on the right column I have – some of these things will be addressed in a new policy development process, and some will be just updated operational guidelines. I think this is an artifact of a previous presentation. Sorry about that.

Discussion points. So one of the most interesting points and part of the reason I don’t have documents to bring to you now, we’ve kind of got into as a committee discussing the role of the public policy meeting.

Like one of our problems that we were originally chartered to address was that the policy development process is too slow in some circumstances, but we have public policy meetings every six months. What is the role of the public policy meeting? Is it required to have a review at the public policy meeting? That’s still an active discussion.

So is the role here, is the purpose of the meeting to inform the Advisory Council so they have a good sense for what the community is looking for? Or is it to find out whether there is consensus on a proposal that the Advisory Council has been working on and says, look, here’s this Draft Policy that we’re looking at, what does the community think, is there support for it.

These are interesting and active questions that are still going on, and of course welcome comment either to PPML or here.

The next steps for the community will be to formalize a draft so we can bring it to the AC and Board. I want them to do one final thing and tell us if they have any alarms to raise. And then it will be coming to community. It absolutely – the policy development process must come before the community before being adopted. That’s who it’s for. That’s what it’s for.

So it will go to PPML. I’m open to discussion on whether we bring it to the next policy discussion before adopting it. And we have some additional areas for work that are interesting potential areas for potential work, either we’ll need to recharter the committee or kick off another committee, but definitely, John, find another volunteer to deal with that.

Here’s some of the other problems that are identified. Openness and how do we make things – make it easy, how do we make it possible to keep up. PPML is an active list. I don’t know if anybody’s noticed that there are a lot of messages there sometimes, so how do we make it possible to keep up with it. What’s the global development process. Who is the community? Are there people who shouldn’t participate? And where is it appropriate to have specific policies for different segments or different portion of our history.

In summary, there have been presentations to the AC. The process documents are in what I hope are final stages and will be coming out soon. And the documents themselves, before we propose them, we’ll be giving them one more thorough cleaning to make sure that they are in fact easier to understand. Because one of the biggest primary goals was to make it easier for people to participate in what is essentially intended to be an open and transparent policy development process.

John Curran: Any questions for Lee?

Louis Lee: Louis Lee, Equinix, ASO Address Council. Thank you very much, Lee, and to the rest of the committee for this work. I appreciate it.

I’m curious to what extent do you expect there to be consideration for the global policy types with regards to this new PDP.

Lee Howard: That is one of the questions that we originally had intended to address. And we actually hadn’t spent much time on that particular point at all. So I expect to bring this initial set of documents to the committee and then hand off the gavel to someone else and work on that in more detail.

And I don’t know whether more work is needed.

John Curran: To the extent that you have suggestions for what should change in our process to accommodate global policy programs, now would be a great time to write them up. You can send them to Lee even if he faxes it to the next guy.

Any other questions? Thank you.

(Applause.)

POC Validation Stats

For people following along in the agenda, you’ll see we’re getting towards the end of the day. Well, we’re still here. Don’t go to the beach. Have a couple of presentations, one of which people asked about POC validation earlier. And I said I would get some information. Leslie put it together. I’m actually going to go through these slides fairly quickly. So POC validation stats.

As people know, we have a program to do point of contact validation, which we started last year. We started with directs and then we moved on to those that are part of your delegations, indirects.

There are 284,273 POCs in the ARIN database, unless you guys added some in the last hour.

We have sent 210,191 POC validation emails. 14 percent of those said, yep, I’m who you are, think you are. 86 percent have not been validated.

This actually is a wonderful return rate, by the way, because a lot of people hate mail like these and delete it. 14 percent is outstanding for validation. But we’re going to keep up with it.

Directly registered POCs with ARIN have a high validation rate, about 36 percent. Reassignment POCs, you assign someone’s space, you put it in Whois, in theory that’s a good contact. We contact them. Either it’s not a good contact or they don’t really know who we are and don’t care. But, in any case, we get 8 percent validation, which is still not bad for validation rate, but doesn’t let us know that those contacts are – that a lot of those contacts are necessarily accurate.

Orphan POCs. This is a POC that’s in the database that doesn’t have a resource now. It’s either been there a long time or it got reassigned, the resource, but the POC is still there. 10 percent of those validate. So just for reference. Random POCs in the database with no resource validate 10 percent of the time. The ones that the ISPs tell us about in their SWIPs validate 8 percent.

I guess if those were both 10 I’d feel okay, but there’s got to be something that can be done to improve the 8 percent in this number.

Now, let’s turn around and look by resource, because that’s sort of interesting.

Of the IPv4 direct-to-network network records, 11,990 ARIN issued. 1568 have no valid POCs. 87 percent, or 10,422, have at least one valid POC. As we talked about, one valid POC is pretty important. Fairly hard to make changes without at least one valid POC since we will actually force that with ARIN Online.

30,000 resource records are legacy. People have one or more records. Actually, a lot of organizations have multiple records, so it’s not surprising. We think there’s about 14,000 legacy organizations holding about 30,000 legacy IPv4 records.

About 14,821 have no valid POC at all. 15,000 of them have at least one valid POC, better than we hoped.

Recognizing we started the program a year ago, it’s pretty good stats for a database that we haven’t been told to proactively groom. We’re now doing that because the community has asked.

Let’s talk about other records. IPv6, the nice bright shiny clean world of IPv6. 94 percent of them have one valid POC. 120 of them have no valid POC. So 6 percent of those records, 120 of them, have no valid POC. We should probably fix that. This is the future. Shouldn’t take much to update.

If you happen to be one of those, please look to see if your POCs are valid.

ASN records. A little bit of a mixed bag. 22,374 total active ASN records. 7,150 have no POCs. 15,224 have at least one valid POC.

We’re going to continue to do this sort of validation. We’d like to get feedback, obviously, from you folks, because we’re sending out mail on your behalf trying to keep this database current that that’s what you want, that’s good. We’d like your support.

To the extent that you’re an ISP and you have customers getting this mail, you might want to tell them about, you might want to have your NOC know we’re validating the POCs, because I’m not sure you network operations center have any idea that we’re sending out these emails based on some of the feedback we’ve gotten.

Any questions on POC validation? Oh, here’s someone. Yes, Ms. Schiller.

Heather Schiller: Heather Schiller, Verizon, who is no longer responsible for this; it’s all you. But my question is: When you log into the portal, is there an easy way for you to see the status of your POC validation stuff?

John Curran: I’m going to guess no, but let me see if someone can disprove me. They’re saying yes. There is? Apparently you can see the status of your POC validation.

Heather Schiller: Now the harder question: Is there a way to see the status of your – the POC status for your down delegation?

John Curran: That’s what I was thought you were asking. Not the POCs for direct. POCs for reassignments.

Chris.

Chris Morrow: Chris Morrow, Google. I looked up to one record, I have the note, 182.8.8 abuse ARIN has attempted to validate from the POC but received nothing from POC you can’t see that unless you look up the POC. The POC.

John Curran: You can certainly look it up in Whois. If you go online – let me ask Mark. Online do we show POC validations that have failed for those resources or also for reassignments? Not for reassignments. I know we do directs.

Heather, I don’t think we’ve provided for reassignments.

Mark Kosters: That would be an interesting suggestion to add as an improvement.

John Curran: Would that be useful to you?

Heather Schiller: I don’t manage the space anymore. Would it be useful, Mr. Middleton?

John Curran: Can I ask that –

Heather Schiller: Okay. I mean, so if I – I mean, in the world when I did manage space, I would think so, because then, I mean, even as a provider, then you can look up and know what your own – you know, you put that information in there thinking that it was the correct contact information, so when you’re trying to contact the customer –

John Curran: You can get one more list of things to clean up.

Heather Schiller: ARIN’s already doing the hard work for you validating that.

John Curran: So if someone thinks that that would help them, please put that one as a suggestion, because we’re happy to do it.

I’m concerned if that list would just become a list that people would never look at because it’s one more thing to do.

Robert Seastrom: We have a question from Kevin Oberman, ESnet: What defines an active ASN?

John Curran: What defines an active ASN records? ASNs that have come back to ARIN are not active. They’re held until they’re put back in the pool.

So these are assigned ASNs, not ones returned, not yet ones not yet assigned.

Robert Seastrom: And it has nothing to do with the presence or absence in the Default-Free Zone.

John Curran: No, not at all.

Yes, Chris, center rear.

Chris Grundemann: Chris Grundemann, ARIN AC. Can you go back to the IPv4 stats?

John Curran: Yep.

Chris Grundemann: I just wanted to check on that. So it just seems interesting that only 14 percent response rate, but a vast majority of the actual records at least have one POC, because there’s tons of extra POCs on all these –

John Curran: Yes. There’s lots of POCs that don’t respond at all. For example, there’s a whole ISP who has a POC in one particular contact field that doesn’t respond for all 10,000 of them.

Chris Grundemann: Also, I just wanted to state that I believe this is important and valuable work and we should keep doing it.

Cathy Aronson: Cathy Aronson. I have a client that has really old, expired POCs, like three or four years ago, because they didn’t know they had a POC. And the process to get it updated is almost seemingly impossible. Like they’d have to recreate the guy’s old email account and then send an email as him, which I didn’t think was a really great thing to do.

So then we tried to set up an ARIN Online account and then maybe try to get the company under it, but they still haven’t had any success with that.

John Curran: So there’s two ways to do it. Actually, I see Tim coming up. You can try to create the email and do that for the alleged organization that allegedly holds those resources.

But the problem is that realistically you’re talking about organization recovery, and we support that, but we need some documentation.

Tim, do you want to –

Tim Christensen: Tim Christensen, ARIN staff. Cathy, specifically to that, if the organization data is valid but if the POC information is not valid, the POC can be recovered. There’s a function in ARIN Online that allows someone to do that and it will allow you to basically reassert authority over a POC record.

Then if the – and I’m going to look at Leslie as I say this, wherever she is in the room, then as things would proceed with the organization, it may then become vetted by registration services.

Cathy Aronson: Is there is some documentation of that that I could point my client at that says how to do that?

Tim Christensen: You would find documentation by the person going to ARIN Online, creating an account, then finding the POC, basically do a POC lookup, and say I want to recover that POC. There’s instructions right on the page that tell them how to do it.

If you’d like, offline I can even show you where to find that.

John Curran: We have to be a little careful about allowing this, but we do allow it obviously because some things have no POCs.

The microphones are open. Last chance on POC.

Okay. Thank you very much.

Now, we have about 25 minutes to our break. We’re going to come back at the break and have Open Policy Hour. This is for policy topics that haven’t yet come up, proposals that weren’t presented here, lunchtime table topics. This is the free-for-all of the policy session, let people get thinking about proposals to be submitted for future meetings.

But before we do that, someone mentioned – actually someone mentioned the fact that we have some interesting stats. Geoff Huston gave a presentation with regards to v6 and routing. And come on up, Geoff.

Observations in dual stack services. That’s what Cathy referenced in her presentation.

Stacking it Up: Experimental Observations on the operation of Dual Stack Services

Geoff Huston: Geoff Huston here. It’s my intent to try and get most of your eyeballs off the laptops. So we’ll see what happens. We’ll take it slowly and ramp up.

I’ve been told, and you probably might be aware of it, too, that June 8th, not June 6th, but June 8th is World IPv6 Day. Yeah, remember that?

And in theory, all you folk doing content delivery and all of you service providers and everyone is meant to turn on v6.

Now, you kind of wonder why. Because you haven’t done it yet. And the suspicion is that you haven’t done it because you’re actually doing something that you’re normally used to doing.

What you don’t normally do is piss off your customers; you don’t normally want to aggravate them.

And the mythology kicking around is that v6 performs like a dog. And the reason why you haven’t turned it on, amongst the many economic reasons, is that it’s crap. So I was kind of interested in understanding whether that observation has any substance or not.

And is this turning on v6 Day an invitation to make the Internet woefully bad for 24 hours, or is this just mythology: How much or how well or how does v6 really perform?

So rather than just simply trading apocryphal stories, I thought it might be useful to measure.

So this isn’t actually some work we’ve been doing, in trying to understand how v6 works and how much you actually piss off your customers when you go dual stack.

So what I’m doing is being a content deliverer, being the Web server, and in effect what I want to do is look at the behavior of average clients out there from the perspective of the Web server when you go dual stack.

It’s actually a really good metric about adoption, because, quite frankly, you can reach me in v6 only when the routing works, the DNS works, everything works, your system works, my system works.

So rather than as we’ve been doing with metrics of v6 deployment, trying to count the packets with v6 headers, trying to count applications in v6, trying to count quad A and DNS zone files, which are all fantastic but marginally relevant metrics, because they don’t really count for what you and I do.

So if you want to see what you and I do, let’s see how many of you respond when I dual stack my service in 6.

If everything works between you and me, I will see you come at me in 6. If something’s broken, you’re going to fall back to 4 or not even try 6.

So let’s have a look at these metrics and actually understand it a bit.

So what we do is pretty typical these days when you measure clients. You do these one-by-one GIFs. One-by-one, because if you put a zero-by-zero GIF, the browser goes: A-ha, you’re just kidding and doesn’t bother loading. So, yes, it’s a real GIF, and the browser goes: Oh, God, not again, I have to do this.

So what we actually did, (inaudible) of them, and we also made sure, by use of DNS wildcarding like crazy, that you have to go to the DNS every time. There is no caching. You have to ask me.

So even if you have intermediaries in proxies, that won’t help. Every time you come to these pages, you get unique DNS names. You have to resolve them. You have to pull down the GIF, and you did work out: Oh, God, it was the same as the last one.

Also, we liberally use cookies just to make sure by giving you these tests we don’t annoy you continuously. As long as your cookie’s enabled, we’re only going to annoy you once every 24 hours.

So I measured like crazy. Not only am I looking at Web logs, but I’ve got extensive TCP dumps and DNS logs and it’s all on the same machine. So I’ve got the same clock running, and I’m testing you in terms of: Did you get the JavaScript? Is the JavaScript coming back?

Are you getting elements from me? Are you looking up my DNS? What’s the timings?

So that’s the methodology of this. And there’s some sort of terminology you get as a result.

If you can only support v4, then you’re going to get the v4 GIF. If not, you’ve really got trouble.

You’ll not get the one that only has the quad A. You’re not going to get the v6. And when you have a dual stack, obviously you’re going to use v4. Whoopdydo. We did find some v6-only folk. Amazing. You won’t get the v4 thing. You will go and get v6 URL, and of course you’re going to use v6 in dual stack. That’s fine.

Also, there’s v6 preferred. Obviously you can get both. When you give and dual stack you prefer 6.

And there’s the other group of folk, that they’ll actually get the v6-only URL, but when presented with dual stack, they’re going to use 4. And then there are the weirdies, the zombies. And in this room there are at least four of you. Good luck.

They’re the folk who will get the v4 object, no problem, and won’t get the dual stack. Just won’t. I don’t see the recording in the Web log. How many of those is important?

Because that’s the folk who, on World v6 Day, are going to disappear off the planet for 24 hours. Those are the folk you’re going to piss off when you dual stack your Web server.

So the first thing, let’s have a look at the ratios of v6 in dual stack (inaudible), every day, every day since May of last year. This is almost a year. Who said that v6 adoption is rising?

If you think from 2 percent to 3 percent is a massive rise, then be optimistic. If you think, oh my God, it’s not, then you’re probably right. That green line down the bottom is when presented with dual stack, between 2 percent a year ago and almost 3 now prefer to use v6.

If I give them a v6-only URL, goes up from 4 percent to 6 percent.

But I’m measuring you people, the people who go to ARIN, your counterparts in Asia-Pacific go to APNIC.net. You’re strange people.

You’re deformed. You’re weird. Because not everyone does what you do.

When I go to the more commoner elements of the world, the less rarefied atmosphere, the picture changes dramatically.

So instead of the seven, eight, 10,000 a day that go to APNIC, I look at a much higher number who go and visit a number of popular sites that are more mainstream.

Totally different, isn’t it? .2 percent. This is since November. Is that green line rising? Only if you’re lying sideways on the bench, right? Flat as it comes.

Only .2 percent of folk are actually going to prefer v6 in dual stack, and nothing’s changed for months.

And of the folk who are capable but won’t, it’s a bit more kind of varied, but it’s up around 4 percent.

So out of this room, I assume there’s about 100, maybe a bit less, only four of you are actually going to do v6 at all even when given a v6 URL.

The other 96 percent of you are going to come up with a browser error. I could not do this.

So when you turn on dual stack, .2 percent of your customers will have something with this v6 Day. 96 percent are going to generate visible errors, because they’re the folks who are going to go, look, I just can’t do it, no matter what, in v6. So things aren’t looking too good.

So if you’re looking for metrics about v6 deployment in the great land of the unwashed, the broad mass market, the 1.7 billion users, .2 percent of the mass best appear to be able to do something in v6 and dual stack.

The good news, if you can control it good, is that 4 percent when pressed, when given a v6-only URL cornered, are going to use v6. That’s only when they’re not given a choice.

And to let a little bit of the cat out of the bag, they’re using auto-tunnelling. They’re using Teredo and 6to4, and they’re the folk who really, really have problems.

So let’s just sort of think about this a little bit, right? This sort of 20 times greater, .2 percent to 4 percent, what’s going on? Why is there so much hidden v6? Why do most browsers actually prefer to use v4, even when they have a choice?

And, interestingly, those browsers still look up the quad A. So this is bizarre. You have this dual stack machine there. It knows that in dual stack it’s going to use 4. Yet, insanely, it goes: What is your quad address? After asking me for an A record.

God, you have a weird operating system. Sorry. Is there someone from Microsoft here? I’m sorry, I didn’t mean that.

It is bizarre, though. Why bother wasting your time? So here are the folk, who, when they’re given dual stack, prefer to use 6, because 6to4 and Teredo distinguish themselves by source address, I know who they are.

I even know their corresponding v4 address. And when you prefer to use v6, you are not auto-tunnelling. You’re actually doing normal unicast.

And, interestingly, most of those folk run Macs. Very few of them actually run Windows. Most of them run Macs.

So very small amount of 6to4, very tiny amounts of Teredo. It’s all unicast. What about the folk who I corner? All 6to4. Absolutely all 6to4. Almost no Teredo, almost all unicast.

So that’s the 4 percent. It’s all 6to4. So pretty typically what goes on, is if you’ve got unicast, the operating system goes: V6 is cool, I’m going to do it.

If you haven’t, then it will only use auto-tunnelling when it has, v6 only, and pretty typically it will only use 6to4.

Now, why did the browser guys do this? Why did they say let’s not use auto-tunnelling even when given the choice? Does anyone still run Windows XP? Good. You and you, if you enabled this stuff, actually use auto-tunnelling in dual stack. Because that’s the way Windows XP ran its preferences. It was actually Vista and 7 that depressed it.

And the reason why they changed that order is that auto-tunnelling runs like a dog. And we will give you some stats to show the dog running.

And the recent operating systems have depressed that auto-tunnelling.

Jason Schiller: Native v6 is still better than auto-tunnelling.

Geoff Huston: Native v6 is pressed all the way up, as we see. It’s back to this graph, that if you’ve got native, you’ll do it. If you haven’t, no, you won’t.

So let’s talk about performance of this. Firstly, the raw performance in seconds of actually doing everything, doing the DNS, pulling all the stuff down, the baseline here, the middle line, is the performance of v4, because you did the v4 GIF. And I’m making sure that I collect all the measurements.

If you use v6 unicast, pretty typically you get the same order of performance as v4.

Myth one: V6 is slower. Not if you’re using unicast. V6 is just as fast as v4 on unicast.

If you’re not auto-tunnelling, you’re just fine. Everything works just as well in terms of raw performance.

Teredo and 6to4: You’re hosed. These are only one-by-one GIFs. These take fractions of a second to load. 6to4 takes 1.2 seconds longer, consistently. 1.2 seconds. Tick, tick, tick.

Teredo, up to three seconds, all over the place. So auto-tunnelling works like a dog. Why?

Two reasons: One, to set up a tunnel takes time. I’m really referring here to Teredo, because 6to4 is basically stateless.

The stateful Teredo setup takes an extraordinary amount of time to setup. I’ll go into why in a second, because it’s kind of fascinating.

And there are a few folk who are really doing the wrong thing in v6 to make this far, far worse than it need be. But, yet, Teredo runs like a pig, because of that enormous setup time.

Secondly, when you tunnel, you go via places. You don’t go direct. So look at 6to4. What actually happens between the client and the server is that the outgoing packets come to me. They go to 192.88.99.1.

And my packets back to you don’t go back to you. They first go to someone, anyone, some stranger, some good-hearted person out there offering a route to 2002/16, who just inclined to take my packets and forward them on for me.

That’s pretty crap. So at least I, as a server, can make life slightly better. So what I’ve done, just to be nice, is I’ve whacked the 2002 in my Web server. So at least I know that the path back to you is the v4 path.

So if there’s any difference in the time in 6to4 – and there was – the difference is in getting the packet from you to me one way.

So the setup time for 6to4, it’s stateless. So this is the distribution in time across all the experiments in a month or so. And basically 6to4 says: Any difference there is really just the browser staggering stuff. 6to4 is quick to set up.

This is the RTT cost of 6to4 tunnels. That’s interesting, because there’s this kind of peak at 150 to 200 milliseconds.

What’s 150 milliseconds away from Australia? California. What’s going on?

Is it for huge amount of folk around that area of Asia, their closest 6to4 relay is one in California.

The least you can do as ISPs, the least you can do, is put up a local 6to4 relay and advertise 192.88.99 inside your network. If you want happy customers, do that.

If you want to piss people off, don’t. Because by not doing that, you’re just making 6to4 tunnels run like a pig.

And that’s where I get the 1.2 seconds from, because that’s basically the load going on in using remote relays.

So, okay, what about Teredo? Teredo is a fascinating beast. Teredo is pretty bizarre. The first myth about Teredo is no one uses it.

Most folk who run Web servers look at these kinds of graphs where ever I did it here, and they say oh, yeah, there’s no Teredo. So I wouldn’t bother doing anything about Teredo. Wrong.

We’ve been actually looking at v6 traffic by looking at the dark space, the space that isn’t advertised. I was actually originally looking for the first signs of viruses and other forms of bad traffic.

Do you know what I found? 98 percent of all traffic is Teredo. Not 6to4. Not unicast. Teredo. Why? Because you guys, you ISPs, hate peer-to-peer, and you do all kinds of deep packet inspection and traps to get rid of that awful nasty evil torenting.

So what does micro torent do? It beds itself down in running v6 encapsulated in v4. And what does it use? It uses the only v6 interface it can find on the local machine, which is Teredo.

And because micro torrents don’t use the DNS, all the traffic is Teredo. So right now most of the traffic on the v6 network is Teredo. Overwhelmingly Teredo.

How do we find Teredo traffic? Easy. Flush it out by avoiding the DNS. If you put up a URL like that, a native 6 address, all those Windows boxes will all of a sudden go: A-ha, I can get there, I will use Teredo.

.2 percent of folk use v6 when given a choice. 4 percent of folk use v6 when not given a choice via the DNS. 35 percent of the network – 35 percent of clients in the great Internet will use Teredo if cornered, held to the wall and bashed up.

There’s an awful lot of Teredo out there. If you think that Teredo is unimportant, and you’re an ISP, then I would contend you’re not actually looking after what your customers do, because there’s an awful lot of 6 in 4. And that 6 in 4 is actually Teredo. 35 percent of your client base by the look of it will do Teredo.

Okay. 30 percent. Now, the bad news is 70 percent of the network couldn’t even do that. Poor suckers.

So the next question is: How good is Teredo? This is a rip-off from some Microsoft thing showing just how many packets it takes to even set up a Teredo tunnel. Nine packets all over the floor.

What’s the setup time? Wow. That’s in seconds. So around 10 percent of the clients who visit me can set this up really quickly.

Around 13 percent are taking at least 600 milliseconds. There’s some poor bastards out there who, nine seconds later – nine seconds later – are just ready to send their firsts in. Nine seconds for every single piece of your Web page.

Wow. Teredo sucks. What about the RTT? Oh, my God, 320 milliseconds longer just to do one exchange.

The way I measure this is I look at the distance in time between receiving the syn and receiving the act. What’s 350 milliseconds away from Australia? It’s not California. It’s not New York.

It’s London. Why is it London? Because you guys out there have decided that the best v6 transit is cheap.

And the only people to offer really, really cheap v6 transit are overlays. So you guys use Arcade.

And Arcade has only one exit policy. If you use Arcade, where’s the closest Teredo relay? Doesn’t matter where you are on the planet.

The closest Teredo relay, according to Arcade, is in London. If you live in London, lucky you. If you live anywhere else, like I do, you’re hosed. Because you’re 350 milliseconds away from the closest Teredo relay.

So performance sucks. And every time you go to the Web page, you take at least three seconds to load one lousy GIF. So at this point unicast is great, but auto-tunnelling is crap.

But, you know, it’s worse than just performance, right? Yes, there are lots of overheads. But there’s a second class of zombies, the folk who never make it to your log file, the folk who sit there and go: You know, I’m trying, but I just can’t do it.

What I was trying to measure next was the number of folk who actually don’t get GIF. They try and they don’t.

Now, the first thing I can do is measure the folk who got the v4 object but didn’t even get the dual stack.

When you turn on dual stack, according to these measurements, .6 percent of the folk who were perfectly fine getting you in 4 will not get you in dual stack.

What will happen is the 6 will work but fail. In other words, they’ll start. But they won’t seem to fall back.

The good news is, it’s not 10 percent. It’s not 20 percent. The good news is it’s less than 1 percent. The bad news is, if you’re 100,000 visitors a day .6 syns is a lot of people. And those people don’t seem to be able to do the dual stack dance, at all. They just fail when they go dual stack.

So I’m still not sure about this metric. I’d like to corner it a bit more. Because I was kind of looking at behavior too far up the stack.

So the next thing I do is actually go one step further. I’m doing TCP dump. One thing I can do is look at the number of naked SYNs out there and see how many naked SYNners there are. Because if I see a SYN, stop it, here’s a SYN-ACK, and will respond with an ACK.

If you’re bad, I won’t see your ACK. In other words, all I’ll see is the SYN and nothing else.

So that’s a good metric on failure. I can look at this in the grand scheme. .001, tiny amount of v4 gives me naked syns.

I’m really not sure why, but it just seems it’s run of the mill. In v6, between eight and 10 percent of all connections don’t work. God, that’s huge. Would you run a service when eight to 10 percent of the folk, of your customers? That’s a massive failure rate.

Let’s have a little look further. And I can break it down by source address, because the syn has a source address.

Where is the failure? It’s all 6to4. Between 10 and 14 percent of all auto-tunnel connections don’t manage to make it past the first syn.

Teredo is weird. We’ll get to that later. Unicast is still high. Unicast is still around 10 to 20 times higher than v4. So even when these unicast v6 folk look to be doing the right thing, the failure rate’s still unacceptably high.

Now, let’s look at Teredo. Teredo is cute because I actually need even more information. If you’re on a Web server, an incoming Teredo, the first thing you see is I see MP.

Hello, are you there? And you’re meant to answer. And then you see the syn. You can actually count the number of failures even before the syn.

I turned this on the start of March. 35 percent of all Teredo connections fail. So 30 percent of the Internet can do Teredo. About 45 percent are trying but not – 30 percent of those Teredos don’t make it.

And the reason why – we’ll get into it – is actually all about ICMP blocking, amongst other things.

So here is now the full picture of v6 awfulness. 35 percent of Teredos fail. Around between 10 and 20 percent of 6to4 fail. And down there at the bottom is basically unicast failure, at around 2 percent or so.

So that’s a summary there. 6to4, pretty shocking. Teredo, really, really shocking. Why does 6to4 fail? Because it’s auto-tunnelling, you don’t know it’s happening.

Your local firewall or filter says: Protocol 41. That’s not UDP. That’s not TCP. That’s evil. So you manage to get the syn out, but the incoming syn ack, on Protocol 41, the local firewall goes, uh-huh, connection failed. This is fine.

What do 38 percent of the Teredo connections fail? Because this is standard NAT reversal. I have no idea. My suspicion is that stun, turn and ice don’t work very well. And that the true horror of NAT performance is worse than anyone really imagined or measured.

And that even quite sophisticated mechanisms – and Teredo is no fool – don’t work very well. NATs truly are shit. And building a reliable, modern performance network on NATs and thinking you can make the network work for the next three years on even bigger NATs is complete folly.

You will not have a network if you rely on NATs. You will have a disaster on legs. This stuff doesn’t work.

Even unicast v6, 20 times higher in your failure rate than v4 is hardly a successful implementation in deployment. We’ve got a lot of work to do.

So what can we say about this? Apart from what I’ve already said, for v6 Day, if you’re thinking of converting to dual stack, go for it. But a small fraction of your clients will go: Oh, my God, your 50-part webpage with all those individual GIFs is running like a dog.

And the delays, if the poor bugger uses Teredo, and the closest relay is in London, they will really notice delay badly.

So a small fraction of them will get a much slower service. Fine. Collect for damage. And even smaller fraction, somewhere around .6 percent, maybe a bit smaller, won’t see you at all, just will not see you at all. Because when you go dual stack, a few folk will drop off the planet on you. Okay. For a day.

But what about the poor person who comes along and says: I’ve got a new service. I want some addresses, please, I want v4.

They go: No, we’ve got no more v4, we’ve run out. What’s today? We’ve run out. Is an IPv4-only service viable? No. No one can offer a v4 service in today’s network using only v4.

One, you’ve gotten rid of 96 percent of the folk who are potentially going to get to you. And, secondly, auto-tunneling is not a solution.

You know, there was this theory out there that Microsoft and Macintosh, and all the rest of these folk, could actually patch up the laziness and indolence of the ISP industry.

But even though you guys weren’t ready to do to v6, it’s okay. We can just tunnel over your mess and get right to the other end of the problem. We can fix it up.

And the ISPs looked at this and said: Yahoo, not only have we externalized the cost of address shortage by making customers buy NATs, we’ve externalized the entire dual stack thing, by making you guys run auto-tunneling.

We can sit here and do nothing, and v6 will just happen and we don’t have to pay the bill. Crap.

Because if you think your customers’ interests are best served by giving them a pleasant experience, you can’t do that with auto-tunneling.

6to4 is not an answer. Teredo is not an answer. Unfortunately, now you have to do three things: You have to run v6, because if you think auto-tunneling is your future, it ain’t.

Secondly, there’s an awful lot of folk already out there who are your customers who are running auto-tunneling and you can’t stop them anymore.

So you’re going to have to run 6to4 relays. There’s also an awful lot of folk out there who are your customers who are running Teredo, far more than are running 6to4.

You need to install Teredo relays as well. So now you need to do all three. You need to put in the relays for these auto-tunneling protocols, and you have to run v6, all at once, and you better do it now. Because happy customers is what makes you money. Poor, sad, pissed off customers is what gives this industry a terrible name.

Can you run these tests? Yes. What we’ve done is actually loaded this up so that if you normally use a tool like Google Analytics, and you have the little analytics code on your Web page, this Web page will tell you how to stuff some more stuff into analytics.

So that without you going dual stack, without you doing anything more than just adding a bit of JavaScript, your Google Analytics report can then tell you what it would look like when you go dual stack, what happens to customers and how many do various things.

So, please, have a look at that URL. And send me back any comments. And it’s now 3:00, and I hope you found that interesting.

John Curran: He has time for two questions and then we’ll go to break.

I see one. Second person get up there somewhere. First question.

Wesley George: Wes George, Sprint. This isn’t as much a question as it is a comment. There is a draft working its way through v6 ops right now. It’s about to be adopted as a working group draft.

It says “6to4 Advisory” in the title. That specifically talks about some things that providers and others can do to improve the way that 6to4 works.

We’re not expecting that it will actually fix all of this stuff, but this is exactly to what Geoff was talking about: It might make it suck a little less.

So if you’re curious about that kind of stuff, I would encourage you to have a look at that on the documents that are currently associated with the v6 ops working group.

John Curran: One more question and we’ll go to break.

Alain Durand: Alain Durand. Comment also. This is not about the new things that we can do to fix the mess.

The problem is there’s a lot of mess out there. A lot of implementation. But replacing these things, and they’re simply going to break until they are replaced.

And with a policy like the one we discussed this morning, we are simply going to make things worse.

John Curran: On that note, you can find people out in the hall. Everyone take a break. We’ll be back in 25 minutes. Thank you, Geoff.

(Applause)

John Curran: Okay. So we have now the Open Policy Hour. This is the Policy BoF session where the microphones are open for discussing any policy matter.

This includes proposals that weren’t presented here. This includes ideas for policy changes. This includes people who have signed up in advance. I have one person who signed up.

So I’m going to call him up. Jason, you want to talk a little bit about global policy; is that it? Global policy, come on up, Jason, and Chris.

Open Policy Hour and Open Microphone

Jason Schiller: So we’ve been trying to do a global policy proposal for IANA to be able to make allocations post-IANA depletion. There’s been three of these, past and current.

I’m going to go through them very quickly to remind you.

First one was GPP-IPv4-2009. And ARIN region referred to it as Policy Proposal 82, Draft Policy 2009-3. It established a recovery IPv4 pool for returns of /24s or larger sized blocks at quarterly intervals.

ARIN changed some of this text so that the return of this space was optional as opposed to mandatory.

And post-depletion, the pool would open up twice a year on regular periods. They would take all of the space in the pool, divide it up ten ways, and each RIR could request up to one-fifth of that space, if it was in a depleted status, meaning whatever that allocation unit was.

For example, if there was eight – if there were ten /8s in the pool, that would be divided up ten ways, ten /8s. Each RIR could request one /8 if they were depleted. And by depleted, they would have to be having less than 50 percent available space in their current holdings. So that would be less than a 9 in this case, and there was a requirement for public reporting.

The second policy we looked at GPP-IPv4-2010, Policy Proposal 115, Draft Policy 2010-10. A little bit more complicated. Established a reclamation pool. Post-depletion, that reclamation pool would be opened up each quarter.

Allocations would be at a maximum /8. And at a minimum the largest RIR minimum allocation assignment.

Allocations would be of equal size to all RIRs in depleted status, and depleted status was defined as having less than a /8 in inventory and at least one pending request that they could not fulfill.

RIRs could put up to a /10 in reserve for austerity measures or other special use. And the RIR must publicly declare that it’s depleted.

There was a public reporting requirement and a transfer policy hook. There was some concern in this community that we did not want to return addresses to the IANA if they were going to go to another community and if those addresses were capable of being transferred without justified need.

So there was a hook there that said if there was a globally coordinated transfer policy, then these addresses could be transferred; otherwise not.

Then we have GPP-IPv4-2011. This is ARIN Prop 137. We did not discuss at this meeting. We will discuss at next meeting.

It’s much like the first one. It establishes a recovered IPv4 pool containing any fragments and any returns to the IANA.

The allocations made when the first RIR has less than a /9 available. And then subsequently, in two allocation periods per year, at regular timeframes.

The allocation unit is determined at the beginning of that period. Instead of one-tenth like the first proposal, it would be one-fifth, rounded down to the nearest CIDR. And there’s a minimum of a /24.

Each RIR gets an equal-sized chunk automatically, and there’s a public reporting requirement.

So I want to try and have some discussion. What we’re trying to find out is, is there support for this new policy, GPP-IPv4-2011, in the ARIN community?

Do we think that this is something that can pass? If there are things you don’t like about it, what advice would you provide to the authors or the AC for modification?

And of the three policies that have been set in front of this community, what qualities do you desire in a global policy in this space to have?

I have some food for thought bullets here. I’ll run through them just quickly. GPP-IPv4-2011 is not needs-based. Each RIR gets the same sized chunk whether they need addresses or not.

It also does not make provisions for preventing addresses from moving from one region with strong Internet stewardship to a region with, for example, an open transfer policy. There’s no transfer policy hook.

Both GPP-IPv4-2011 and GPP-IPv4-2009 have two allocations per year. And GPP-IPv4-2010 has four. GPP-IPv4-2010 depletion is measured as having less than a /8 available, and you can only count up to a /10 in reserve for special use. This may disqualify APNIC and RIPE, whose austerity policies will leave most of an 8 unutilized.

And it may also disqualify the ARIN region, who has already reserved a 10 for austerity and is considering putting aside a 16 for critical infrastructure and an additional /10 for a shared transition space.

Should we consider changing this to an 8 and resubmit GPP-IPv4-2010? GPP-IPv4-2010, also people had concerns that an RIR may teeter in and out of depletion status.

Should we add some language that changes this saying that an RIR is considered depleted, if they move into a status at any time in the previous period after they got their last allocation from IANA?

Lastly, there was a concern that when it’s initially activated, if only one RIR is in depleted status at the beginning of that next quarter, that they would suck down all address space.

Should we write some policy to limit that? Should we have some sort of delay to allow other RIRs to deplete? How long? Is it fair to delay it when there’s people that need addresses? Is there some other rule that says one RIR just can’t empty the pool?

And, lastly, the question is: How do we proceed? Should we deprecate GPP-IPv4-2010 and 2009? Should we modify IPv4-2010 in hopes of gaining consensus in APNIC and LACNIC?

If so, what modifications do you think we should make? Should we try to combine some parts of 2010 and 2011? If so, which parts do we like?

And what advice would we provide to the authors of 2011?

Lastly, we’ve had some tabletop discussions about this topic and some interesting ideas have come up, and we’d like to share those as well.

Chris Grundemann: So this is one alternative that actually came up yesterday at lunch, I believe. David Farmer recorded it at the AC table, which is basically that – and it kind of follows with ARIN’s, the staff policy assessment that it is potentially possible that already today folks outside of this region could potentially request space through the ARIN framework.

So the idea would be to codify that into policy and state unequivocally that organizations anywhere in the world can apply for and receive space through ARIN, whether it be an allocation and assignment or a transfer.

And then, of course, that would follow the regular rules of ARIN, which means that the space would remain under the stewardship of ARIN. All of the policies of ARIN would apply to that space. And when returned or transferred, it would still abide by all of the ARIN rules.

This would basically take IANA out of the equation and allow space recovered, returned and transferred within the ARIN region to be accessed by the entire world.

So that’s one idea.

Jason Schiller: It’s also important to point out we thought this could possibly be a globally coordinated policy where there’s no action required by other RIRs except to accept the policy and rubber stamp it. And we suggested there might be a clause where this gets automatically revoked if there ever is a global IANA policy for allocations post-depletion.

So I’d like to hear some discussion on any or all of this.

John Curran: Microphones are open.

Raúl Echeberría: Raúl Echeberría, LACNIC. First point, recently in the Address Council meeting in San Francisco, somebody proposed to use a common numbering system for all the RIRs when we discuss global policies.

I have to admit that it would be much easier if we could identify more easily which proposal are we talking about.

So I have some confusion. While listening to Jason, I was trying to match those numbers with the numbers that are being used in other regions.

But the second point, I think that we have to do that, continue saying that it would be useful. We have to do that.

Second point, I think that we need a global policy. We need a global policy that involves IANA, because we are talking about how IANA will manage the returned addresses.

When we had the discussion about the first global policy that was presented, it was difficult to get consensus in ARIN region, among other things, because there was not a clear consensus in the point of, if the returned address, it should be mandated to return the recovered addresses to IANA or not.

So I guess that the people that have promoted the other policies tried to remove from the table that discussion in order to get consensus.

If we say – if we would say that the return of those addresses to IANA could not be mandatory, it could not get consensus, because many people would not support that idea.

So the best solution is to not say anything about that and concentrating on how IANA manages the address without saying how the IANA get those addresses.

So I think this: We need the global policy. I think that sometimes the difference between the last two proposals are not very big.

I guess that if the people could talk with each other, I think that it could not be difficult to get consensus.

In fact, the last proposal is people in ARIN region have told me that they don’t like the last proposal that is being discussed because it’s not needs-based.

And I don’t think that this is the idea of the authors. So I think that some clarification is needed. I think we can introduce the modifications.

So what I recommend strongly is that somebody from the Advisory Council could be in touch with the people that is proposing this policy in order to tell them, explain to them what is the feeling, the spirit of the ARIN community, and what things should be included or removed from the proposal in order to be able to reach consensus in this region.

I think that it could be very helpful. This is my recommendation. Thank you.

Chris Grundemann: Just a quick point of information on that. David Farmer and I are the shepherds of that proposal, and we have been in communication with all the authors.

Mike Joseph: Mike Joseph, Google. Concerning not the three global policy proposals but the option mentioned at the end, concerning ARIN to just accept registrants outside of region. I actually have a question for staff on this point.

Based on recent comments to PPML, it sounds a lot like this would violate our contract with the IANA, or with ICANN running responsibilities for RIRs operating within each region. Can you comment on that?

John Curran: This is John. I’m not going to answer the exact question you asked, but I’m going to come as close as I can safely.

There’s a globally coordinated policy in existence already called ICP2, which has some reasons why there’s a single regional Internet registry serving distinct regions. It appears to this would be contrary to that. I’m not sure how a global policy that was contrary to another global policy would get resolved.

But it certainly looks like it conflicts the existing ICP2 policy.

Mike Joseph: It sounds like by the proposal, this would not be a global policy, but a local policy, conflicting with the global one.

John Curran: There’s no assumed precedence either way. We would have a policy conflict that hopefully would be resolved before anyone had to turn the crank and implement it. Since ICP2 is a global policy, resolving something against it would take some time.

Bill Darte: Bill Darte, ARIN Advisory Council. So all of these solutions seem to me as being, you know, very engineered solutions to an issue that I’m not sure exists.

Not to my satisfaction have I ever heard anybody try to authoritatively establish how much space is likely to be voluntarily returned to any one RIR.

What the probability and what the scale or magnitude of those returns are likely to be, given the fact that there are transfer policies in place in regions and now presumably between regions if some sort of accommodation can be made to 2011-1.

And I think that’s fundamental to the discussion.

John Curran: I can answer the question with respect to the ARIN region. But I can’t offer it to other regions.

In the ARIN region, there is first an address block which was returned for community use by Interop. The 254th or 256th of the block, it’s a /8, of which that fraction was returned and is in hold-down per ARIN’s policies. On May 22nd, that will come out of hold-down and staff will seek advice of the Board regarding disposition of that block, and that block is certainly eligible to be returned to the IANA.

The IANA has said it would exercise stewardship over any blocks returned, even absent a policy for distribution. That block could be used in the region.

We had a policy that obviously in the AC discussing exactly what might happen to such address blocks.

So that’s certainly some address space already. There’s other parties. ARIN – after February 3rd of this year, when the final /8 was returned – I’m sorry, when the final /8 was assigned, we had a number of organizations contact us and say we didn’t know you were running out. Here, have our address block back because we don’t need it.

After a conversation that started off with you know these could be monetized, are you sure? ARIN did receive address space back. So it’s not inconceivable.

So the – and additionally, from time to time we’re in discussions with organizations that go similarly. So I don’t think there’s necessarily a huge quantity, but I do think it’s inevitable through our processes that there will be some return space coming back over time into the ARIN region. It may not be all that large.

Bill Darte: Might be probable, but not necessarily –

John Curran: Correct.

Martin Hannigan: Martin Hannigan with Akamai Technologies, and I’m a member of the ARIN Advisory Council.

I want to just offer a quick reminder that we do actually have an adopted global policy in the region which at the meeting that it was passed, it was consensus of 40 to 5.

It was a pretty strong statement in my opinion; and I think that when you correlate that one against the most recent one, that there’s some significant differences in that, with the level of support that we had then, we should be cautious to consider usurping what we’ve already done.

With that said, I don’t think that it would be negative to entertain the idea of reopening the discussion. But I think at some point, as we just read about the Winklevoss twins, the game has to end at some point.

I think I’m broken at this point. And I agree with what appears to me to be a majority of the community, that we need to stop talking about this and we need to move on and get it over with.

I think that we’ve seen signs and demonstrations of facts that would allude to more address space not being returned than being returned.

And that the effort that we’re putting in to trying to solve a problem that may not exist is outweighing the benefit.

Personally, I’ve had arguments with people. This has been a big learning experience for me. I still don’t think I know everything that you need to know about the RIR system. For example, the various registries issue. That was an eye-opener.

We learned something new every day with respect to how things kind of happen in the back channels. And to be honest with you, I think the one argument that comes to mind, aside from the financial benefits of people selling address space – and let’s not have the discussion whether that’s legitimate or how it’s related to transfers and whatnot, we can argue that point tomorrow – but I think at the end of the day, it came from the U.S. government. Maybe we should send it back to them and let them dispose of it, if anything does get returned.

Or maybe we should let some kind of market actually develop and do our peace as our community desires and let the United States taxpayers get a benefit from the address space that we initially funded its creation.

I’m not suggesting that we operate in some kind of closed boxed, in nationalistic fervor, but I really don’t see that this issue will ever be resolved. I think that there’s such a huge difference in opinion on what we should do that it would be quite easy for us to talk about it for the next two years; and if that’s the case, then we can continue to do that.

But by the time that that actually happens and we close the discussion, I think it will be way too late to have any influence on the way this thing is going to wrap up.

Thank you.

John Curran: Over the long term – while short term we still have people returning address space to us. Though, it’s not huge, and it may not necessarily grow. It does happen.

Over the long term, multiple years or decades, there is an agreement in place between ARIN and the U.S. Department of Defense, whereby the address space that they no longer need that they don’t need for any other agency of the U.S. government, they agree to return to ARIN.

So depending on the time frame that you’re looking at, this may or may not be relevant. If you’re thinking in the next five years, that might not matter. If you’re thinking about v4 address returns over 20, it probably would.

Martin Hannigan: Just a comment on the DOD remark, John. I think in the short term, and maybe you did say this and I’m just not clear, I don’t really see the DOD turning any addresses in.

I think they’re going to hold onto them for their own v4 needs, and that maybe at some point down the line, hopefully when transition is well underway, that this will be a moot point.

Thank you.

John Curran: That’s what I think I said, yes.

David Farmer: David Farmer, University of Minnesota, ARIN AC. This is in response to Raúl about, I think, pushing that there may be some misunderstanding.

I want to say that I’ve been in communication with the primary author, Philip Smith, and I’m not just going to read his email because it’s a private email.

But essentially it is, no, it says as intended; they intended it to be not needs-based, and it was a sticking point in the discussions of our, the proposal – the middle proposal of the three in APNIC.

And so we’re going to need to find – if we’re going to do something, we need to find some compromise between some various groups of folks.

We’re not all going to get our way. And so we need to find some compromise.

Scott Leibrand: Scott Leibrand, ARIN AC Limelight. I think this is an important issue. As we’ve been watching the graph, APNIC space is now down to .03 /8s left before they go into the final /8 policy.

Unidentified Speaker: What time is it?

(Laughter)

Scott Leibrand: I’ve been refreshing that page. I’m not sure how frequently you update it. The last I checked, we have over five /8s left in the ARIN region. There’s going to be some serious pressure for organizations that can no longer get adequate amounts of space in the APNIC region to get space from other RIRs.

I’ve heard people say that it’s perfectly valid for organizations from other regions to set up an entity here and get space and what they do with that space is an open question.

There are the possibility of inter-RIR transfers that we’ve been discussing. There’s the possibility of going back through the IANA, but somehow or another those addresses are going to find their way to – into networks that need them. And whether we slow that down or not, it’s going to happen.

And I think the risk to our community is that if we have too many things in place trying to prevent addresses from moving, that they will move outside the system. And that, I think, is harmful.

So I’m not sure how much we can do in the very short term to address this, but it seems like a very important issue that we need to be willing to compromise on.

As far as I can tell, the needs bases is something that served us very well and is continuing to serve us well in this community for now. But at some point I think needs bases is going to be a check box.

If you’re applying for space, if you’re willing to spend however many dollars per IP to get space, you most likely are going to need them.

And in most applications I think that’s going to be a check box. And these differences that we’re seeing in policy between our region and APNIC region are going to become less relevant, I think, as that becomes more and more of a check box and less and less of a qualification.

So I think that’s something else to keep in mind as we consider these global policies.

Paul Vixie: Paul Vixie, ARIN Board of Trustees. So with respect, there are reasons to be willing to spend money to get addresses other than other than because you need them.

And some of the impact, social impact, environmental impact, if we had an environment here, digital environmental, should concern us if that happens at scale.

Scott Leibrand: Yes, I think it is highly possible that if we were to allow completely free acquisition of space currently now while there is a bunch of space unused, that that space could go to an organization that wishes to speculate on the future price of addresses that they might horde them and not put them into use on a network.

That’s why I say that needs basis, I think, is still useful. I think at some point the free addresses out there that are free to be had for next to nothing or even for a lower price than people expect in the future, that’s going to diminish to the point where speculation is no longer as much of a concern.

I don’t know how long that’s going to take. I don’t know how it’s going to develop. But we should keep an eye on how things are changing around us and not get stuck in a situation of applying something that was more useful in the past than it will be in the future, blindly, without considering how things might be changing.

John Curran: So one of the questions that comes up is: At present, for example, transfer policy in the ARIN region recognizes that the recipient has to have qualified need.

That actually turns out to be not fully recursive, but somewhat recursive, because it then effectively refers you back to the same qualifications that you would need to receive an allocation. Those qualifications have different properties they protect:

Minimum allocation size; maximum allocation size; how much effective allocation you can receive.

And those are – behind those are certain principles. One of the questions that comes up is: Are all the principles behind our current allocation policy all equally valid in a transfer policy? Because right now you get them all at once.

You qualify for a transfer if you meet the qualifications for an allocation.

And that actually turns out surprisingly to match the words in RFC 2050, which says transfers may happen if you meet the same qualifications that you make for an original allocation.

But it’s not inevitable that all the qualifications for allocation would all need to be in a transfer policy.

The definition of need should be matched to whatever goals the community actually wants, and I don’t know what those are or how those will evolve over time. But it’s worth thinking about the requirements individually and not just the same as allocation policy.

Wesley George: Wes George, Sprint. Can you go back to your Food for Thought slide.

Jason Schiller: I have two of them.

Wesley George: The one that talks about the /10 versus /8. That one. I actually wanted to comment specifically on that.

I am not in favor of changing that to a /8. I think as we get further along into exhaustion, as it sort of gets to the peak before it stops mattering, I think that all the RIR communities are going to be forced to make some difficult decisions about what’s important.

There have been lots of folks who have been saying, look, we need to kind of squirrel this stuff away for a rainy day, because we’re not sure exactly what we’ll need it for, we’re not sure what’s going to be a big deal. We don’t know what we don’t know, basically.

But at some point we don’t want this stuff to be stranded. Some of our stuff has gone in with a sunset policy of some sort or another under the expectation if we haven’t figured out a use for it by then, we either need to do policy update, or it needs to go back into the pool where it can be used for something it can be used.

I don’t think we want to put a loophole in that rewards sort of limbo allocations of space.

And I think, if anything, if you were going to try to make this a little less of a problem in terms of disqualifying, it might be that you try to put some words around whether or not it’s actually in use.

We have things like 4.10 where we’ve got a block that’s reserved. And unless we figure out what we want to do with it, it’s going to sit there. That might not meet the test; whereas, if we say, for example, that one of the other policies passes and we carve up a set of space for either shared address space or for critical infrastructure and those are actually being used, we can say, look, this was a legitimate, justified reason for doing reservation, and, therefore, we’re not wasting space.

I would rather see it go that way than to just wholesale raise the number so nobody gets impacted by that restriction.

Jason Schiller: Let me make two points here: The first point is: This only refers to the amount of unused space that is in reserve. The used space is not counted.

So if APNIC and RIPE decide they want to set aside a /8 for austerity measures, and three of the 10s are consumed, we only count the 10 that’s in reserve.

In that case they would qualify to get additional space. However, if they put a /8 aside, today the second policy, GPP-IPv4-2010 as written, if they put 8 aside and only one /10 of that 8 is used with three 10s being reserved, that would not qualify them for depletion status.

Because the way the policy is written, it says you can only set aside a /10 worth of space as reserved which is not used.

It doesn’t mean – if we change it to an 8, it doesn’t mean that ARIN needs to set aside an 8.

They can still only set aside a 10, and some of that 10 could be consumed, it just means that if APNIC sets aside an 8 and a large portion of that 8 is not consumed, they would not be disqualified.

This is one of the reasons why APNIC didn’t move forward with GPP-IPv4-2010 because they felt they would never qualify to get additional space, because their austerity pool would be mostly unused for a long time.

Wesley George: And that’s where I would respond by saying that is the choice they made and they need to live with that.

Jason Schiller: And we don’t have a global policy proposal ratified through all five RIRs and the IANA.

John Curran: Microphones remain open.

Any other feedback?

Jason Schiller: How to proceed? Should we deprecate GPP-IPv4-2010 or GPP-IPv4-2009? Should we suggest modifications to 2011? Should we try to combine 2010 and 2011.

Geoff Huston: Geoff Huston, APNIC. Neither in favor or against any of those, but I would observe that if five communities can’t work things out, other bodies will do this and will quite happily volunteer to work it out, irrespective.

You’re actually at one of these sort of critical points here where it is necessary for all of us in our communities to achieve some level of compromise that demonstrates we can work together.

And I heard Wes’s comments, and I must admit I was a little bit concerned that if we start going well, so be it, if we don’t agree, then we don’t agree. If we don’t agree, then other bodies will say, I’m sorry, we can do a better job.

I think we can do a better job. And I think putting hard lines behind austerity measures on a /8 and /10 don’t really get you to a productive outcome.

So I applaud asking Philip what his views are and trying to actually gain some impression here on what will work and demonstrate to a much larger audience that as five regional communities, we can work together.

So not giving you any particular direction here, Jason or Chris, but observing this is actually one of these critical test points where we have to demonstrate that we can work together. Thank you.

Jason Schiller: Raúl, you suggested we should provide some advice to the authors of GPP-IPv4-2011 with regard to not being needs-based. I see you at the mic again.

Raúl Echeberría: This is a question.

Jason Schiller: Go ahead. I wanted to state the only advice on how to proceed we got was from you, and that was to provide some advice about how to proceed.

Raúl Echeberría: I just wanted to endorse Geoff’s comment.

Louis Lee: Louis Lee, Equinix, SAOC. Geoff’s comments also endorsed. I wanted to say that if we moved what we count, what we don’t count, move it to /8 rather than /10, and what we don’t count as part of the eligibility requirement, there is still an eligibility requirement.

So that’s still there for needs-based. So think about that. That’s one way we can make a little compromise and have the other side realize that we’re doing that and we’re still not giving up on the needs-based if that’s what we really want to do.

David Farmer: David Farmer. I may be missing this, but I think in the current version of the 2011 policy, our R-137, it’s a /9. And that’s what APNIC is proposing. It’s slightly different, I understand.

Jason Schiller: No, no, let me be clear. So GPP-IPv4-2011 states that an RIR, that the recovered pool opens up when the first RIR depletes below an available /9, which does not include space which is reserved, any and all space which is reserved.

David Farmer: Okay. I missed that part. I’ve been reading it too many times.

Jason Schiller: Any other advice on how to proceed?

Geoff Huston: Geoff Huston, again neither for or against, or even offering you specific advice. I would offer you some experience we had in developing the transfer policy in APNIC. One was trying to address this very same problem in a subtly different way.

And at one stage we commented and talked about the idea that if you recede the allegation within X years before today, you couldn’t transfer it. So it kind of ring-fenced the more recent stuff into needs-based and said, quite frankly, if you’re lining up in this queue, you can’t also monetize in that queue.

And you might want to see with other folk in other communities, if that addresses the concern in the ARIN community about getting these allocations and immediately monetizing it, and at the same time implies sufficiently ways in other communities who see a more different approach to transfer, if that kind of ring-fencing might be an adequate protection for the perils that you are going to see.

I don’t think you’ll change APNIC’s transfer policy by this. Given that, how do you create a framework that meets some of your community’s expectations and addresses some of the concerns in others.

So I proffer that as some experience we had talked about, didn’t put it into the transfer policy, but it wasn’t thrown out at the time. It was just one of the ideas considered.

Thank you.

John Curran: Any other people at the mic? Okay. That’s the feedback you got. Thank you, guys.

(Applause)

John Curran: Okay. Microphones remain open for Open Policy Hour, for at least a little while, then we’ll move on to open mic.

Open Policy Hour is for policy issues, policy proposals not presented here, new thoughts on new policies. Good ideas. Bad ideas.

Microphones are open.

We have all the policy proposals we need and we’re good?

Scott.

Scott Leibrand: Scott Leibrand, ARIN AC. One of the things that came out of one of the lunch tables was some discussion around ways to improve access to the transfer markets.

And just looking at how transfer markets are working so far, given the small number of integers of data points we have.

And one of the things that struck me is that it looks like we have demand for the transfer of IP addresses on non-CIDR boundaries.

Given the prices involved, people seem to want to sell 537,263 – picking a random number in the right ballpark – integers or IPv4 addresses completely irrespective whether they’re outside the CIDR boundaries or not.

Looking at some of the actual real world stuff that we’ve seen recently, I’m not convinced that we have 8.3 quite in the right place in terms of what we allow and what we don’t.

That is to say some of the transactions being proposed, if they’re otherwise needs-justified, what seem to be blocked by 8.3 solely on the grounds they’re not a single CIDR block, and that to me seems a little bit excessive.

I look at that transaction and say, okay, if that were needs justified and were applied for under 8.3, I actually don’t see any reason why we shouldn’t allow it if it’s five CIDR blocks. I don’t know how many it is.

But a hypothetical transaction were five CIDR blocks from one organization to another, in order to transfer the amount of space being desired, I think that would be okay.

And so what I would like to get feedback from the community on is should we look at relaxing that particular one CIDR block aspect of 8.3 to recognize some of the apparent realities of what people want to transfer and attempt to make it easier to do such transfers inside the system as opposed to outside.

John Curran: So microphones are open, regarding the CIDR block limitation in the Transfer Policy 8.3. Go ahead.

Owen DeLong: Owen DeLong, Hurricane Electric. When we were creating what the Board later turned into 8.3, we started out with a policy that had lots of nice complicated language around accomplishing exactly what Scott is describing.

We chose to abandon that in favor of simpler language. There is no simple way to express the desire to do what Scott is talking about without also allowing lots of things we didn’t want to allow, like large-scale disaggregation of the Internet that would be considered rather harmful.

So I would be opposed to changing this unless we go back and relook at significantly more complex language that we had that we felt would actually do what we wanted and not do what we didn’t want to do.

Kevin Blumberg: Kevin Blumberg from The Wire. I actually fully support Scott on this based on my little attempt yesterday in regards to the 12- to 24-month easing.

I had more discussions with other people as well. And the reality is that we are moving away from a system that you could just get what you needed to. We’re moving to a whole different ballgame and keeping it as simple as possible while still being needs-based and fulfilling that community, the community’s wishes on needs-based but keeping it as simple as possible.

As far as disaggregation is concerned, the reality is you can take a /14 and strip it out and strip it down to /24s and sell those off. That’s perfectly fine. But you can’t go out and buy a /14 worth of /24s. So it’s one-sided right now.

I don’t know if it needs to be one-sided or if some reasonable limits could be put in place. Thank you.

John Curran: Microphones remain open on this.

Scott Leibrand: So, Owen, what I was thinking of, I fully recognize that we could make this very complex and that it didn’t succeed for that reason.

I’m thinking something along the lines if a single entity wishes to transfer a certain amount of addresses to another single entity, and they do it in the minimum number of CIDR blocks possible to accomplish that transfer, that should be okay.

I think we could do policy language around that that’s somewhat more complicated than what’s in the transfer policy now, but I think that would accomplish a very real goal in terms of allowing legitimate transfers to occur within the system.

If people have opinions one way or the other on that kind of idea, I’d like to hear them.

John Curran: Microphones are open. Owen.

Owen DeLong: So the problem I see with that is that the definition of “minimum number of CIDR blocks possible” depends on whether you’re looking at the mathematical minimum possible or whether you’re looking at the organization’s idea of, well, we sparse allocated all these 24s and so the only way we’re able to transfer 16 of them to this other organization is to give them these 16 discrete 24s that aren’t currently in use, which I would not particularly want to allow.

I would rather that they renumber out of the things in between and number into the holes in their own organization and make a contiguous /20 available.

So part of the reason we allowed financial incentives was to encourage people to do the work necessary to free up the blocks along those lines.

So I think the policy language is going to be more complicated than you may be thinking in order to achieve that.

Jason Schiller: Jason Schiller, UUNET, Verizon. You all know that I’m going to say that I prefer things that create the least number of fragments in my routing table.

That aside, if you do decide to move in this direction, I suggest you need an additional clause that not only transfers the blocks in the minimum number of CIDRs available out of the available space, but also minimally fragments the existing available space that that organization continues to hold.

For example, if I have a /8 and I’m using two 24s randomly in the middle of it, it would not be a good idea for me to transfer a /24 right smack in the middle of it.

It would make more sense for me to do it to adjacent to one of the two 24s I’m currently using.

John Curran: Question, Jason. So hypothetically it’s a global routing table. And I guess I’m trying to figure out, to the extent that we have policies in this region that support needs-based transfers but with a high level of respect to the impacts to the routing table, and in other regions there’s transfer policies that have less respect to the impact to the routing table, don’t you suffer the routing impact regardless of which – regardless of whether we have the policies, you’ll suffer the routing impact of the policies that happen in other regions.

Jason Schiller: Yes. However, if all the regions are doing it, I will suffer the impact more. And just because one region has less stewardship doesn’t mean we should lower our bar to meet it.

John Curran: Just asking the question for reference. Microphones remain open regarding relaxing of 8.3 with respect to aggregation and CIDR.

Cathy Aronson: Cathy Aronson. Jason, if you could, it would be just super cool if you could maybe propose some text and send it out, because we really struggled with how to write that, and it was really nontrivial.

So if you have some ideas, we’d certainly love to hear them.

John Curran: Center rear microphone.

Wesley George: Wes George, Sprint. I guess the question back to you, Cathy, would be: Are we sort of assuming that this is a problem we need to solve?

Currently what we’re saying is essentially the example transfer, the hypothetical transfer that has been wandering through the news, it would essentially be prohibited by current policy.

John Curran: Hold on. You just said the hypothetical transfer and the transfer in the news. Which one are you talking about?

Wesley George: I refrain from answering.

John Curran: If you’re talking about hypothetical transfer, go on. If you’re talking about something else, you gotta let me know.

Wesley George: I’m talking about a hypothetical transfer that has shocking similarities to the one that went through the news.

Anyhow, my point is, as far as I can tell, because that was broken up into multiple blocks, you know, you can’t run the math and get 600,000 IP addresses in a nice even CIDR block.

It sounds to me, my interpretation, not staff interpretation – and I’m not going to try to pin you down on a staff interpretation right now – that that would already be prohibited.

So I think – Scott and I talked about this, and I think the sense I was getting was the only reason we would need to make a tweak to the policy to cover things like this would be to make it more open to cover cases like this that are seemingly legitimate and otherwise might take place outside of our purview altogether.

So I’m kind of – so I’m not certain we’re at the point of suggesting text as much as we are trying to get a handle on is this something we care about.

John Curran: Yes.

Cathy Aronson: The reason I suggested sending text as A, then we get to see exactly what some of you folks are thinking about, and we could discuss whether it made sense to change the policy that way or not.

I’m not just saying we’re looking for text to change the policy, but it gets a boundary around the discussion with some actual text that says this is what I need. And then we could all look at it and say does it really make sense to change the policy that way.

Because if we had the blanket statement, oh, it would be nice if transfers happened in multiple blocks, that made sense, well, what does that mean?

Wesley George: Since I’m here, I will echo Jason’s comments about referring things that don’t port to the global routing table.

John Curran: Microphones remain open. Jabber comment.

Robert Seastrom: Joe Maimon from CHL says: I offered two proposals that were abandoned by the AC and unsuccessfully petitioned.

One proposal attempted to have ARIN try to ensure that new entrants, as well as small resource holders, continue to be able to obtain some amounts of space from ARIN past general exhaustion.

The other proposal was to reserve the entire /8 for explicit policy instead of business as usual. I think he means the last /8.

Beings as there seems to be one more meeting before ARIN reaches exhaustion, if anyone does have any interest or potential support for these ideas in some form, please drop me a line at jmaimon@chl.com.

John Curran: Okay. Open Policy Hour. Microphones remain open on any topic. Any policy topic, any policy ideas?

Yes, center rear microphone.

Chris Grundemann: Chris Grundemann, ARIN AC. This is just a hairball idea that came to me when we were looking at the POC validation stats, that perhaps through policy we should tie the requirement for valid POCs on downstream SWIPs to your utilization metrics.

What I mean is, if you have downstream SWIPs that have no valid POCs on them, that that space should not be counted as being utilized.

Perhaps that would alleviate some of ARIN’s problems contacting those folks because the ISP would be required to do it.

John Curran: That would certainly end up in the creation of many responsive POCs. Not sure if “valid” would be the right word.

(Laughter)

John Curran: But microphones are open. Please comment.

Mike Joseph: Mike Joseph, Google. I think that would just dramatically increase the number of RWhois servers operating on the Internet.

John Curran: Other comments? Okay. I’m closing the Open Policy Hour.

Any other comments on policy proposals, policy issues we haven’t discussed?

Robert Seastrom: Tony Hain says: This should be relaxed because all the FUD related to deaggregation coming from providers that intentionally deaggregate their existing blocks rings hollow.

Effectively, the complaint is you can’t pollute the space I intend to pollute.

John Curran: Okay. Good comment, or another comment. All right. Last chance.

Wesley George: If I might respond to that. That’s big words coming from a router vendor.

John Curran: Ouch.

(Applause)

John Curran: Let’s talk to the merits of the issue and not the people speaking them. Okay. We all have pedigrees. Let’s all talk about the merits of the issue.

Last chance on policy issues, policy questions that have come up. Lunch table topics. Policy proposals not discussed. General advice to the AC. Okay. Thank you.

I’m closing Open Policy Hour.

We now move into Open Mic. This is – yes?

Cathy Aronson: I have an item.

John Curran: Go ahead, Cathy.

Cathy Aronson: Hi, Cathy Aronson. I have a question for y’all. And it comes from the talk that I gave.

I was wondering if you think that we should be doing some sort of measurement of IPv6 readiness of the ARIN members or folks that have address space, I guess. And what would the list of criteria be? Like RIPE has like you have a route 6 object. You have a quad A record in the DNS. You know, that sort of stuff.

I wondered if you thought that was a useful exercise for us to be doing.

John Curran: Comments on tighter linkages between the two.

Go ahead, Scott.

Scott Leibrand: I get the impression that there’s a lot of good work going on in that space. I really like Geoff’s presentation. I think what we would need to be careful of is that we’re not just redoing something similar on a separate but mostly overlapping user base.

So if we think that there’s some unique thing that ARIN can do here in terms of their data and analyzing their stuff, I think that would be useful.

If we just put up Geoff’s tool on ARIN.net, I think we’ll get more or less the same results that we got on APNIC.net.

So I would love to hear ideas for things that ARIN could do uniquely with the information they have in the registration database or something like that.

I think they’re doing a good job of cooperating with lots of other organizations to do a lot of the other stuff without overlapping efforts too much. And I’d like to make sure that doesn’t happen as well.

John Curran: Okay. Remote participant.

Robert Seastrom: It’s me.

John Curran: R.S. Mr. Seastrom.

Robert Seastrom: Could Mark Kosters come up to the microphone and tell us if we were to go and have IPv6 readiness assessment for ARIN customers that were predicated on being able to find a route 6 object in ARIN’s component of the IRR, whether we would discover that there was nobody who was IPv6 ready still

John Curran: Mark, do you want to comment on that?

Mark Kosters: Parsing, parsing.

Can you say that again in a more simple manner?

Robert Seastrom: More simply, is it still impossible to register route 6 objects in the ARIN component of the IRR?

Mark Kosters: You can do route 6 objects in the IRR.

David Williamson: David Williamson, Microsoft TellMe.

I think we should do something. I don’t know if we need T-shirts. But some way to identify organizations at least to themselves that you’ve gotten to be this tall and you’re riding the ride correctly.

It would seem it would have some value to a number of organizations, especially as we get from the organizations represented in this room to the broader community, just some way to tell you’re doing it right would be great.

Unidentified Person: A logo program, is that what you mean?

David Williamson: Perhaps.

John Curran: Measuring their degree of ARIN-ness.

David Williamson: The right program – I just glanced at it quickly. I didn’t look at the detail. But it seems kind of cool. And you have a set of clear criteria.

There’s some guidance about how to do some of that stuff. And at the end you get a T-shirt. But it seems kind of cool. If we do something similar, even if we just rip them off entirely, that seems like it might have some value to the ARIN community.

John Curran: Microphones are open.

Center rear mic.

David Farmer: David Farmer, University of Minnesota, ARIN AC. In the higher education community, we call this the CIO Gold Star Program.

In Internet2 we sort of figure out the things the community wants done. And then we measure them, and we put up the list and you get your check boxes; and if you don’t have your check box, this gets brought up in front of one of the meetings with the CIOs, and the CIOs start calling all of their engineers and stuff and saying: Why don’t I have my check box.

It is actually quite effective.

John Curran: So you have such a check box for IPv6-ness?

David Farmer: Yes, we do.

John Curran: Wonderful. Are you suggesting that ARIN should have a program to that effect?

David Farmer: Probably not a direct copy of it – David Farmer again. Probably not a direct copy of it, because the relationship between Internet2 and the member organizations is significantly different and there are different kinds.

So I’m not sure a direct mapping works, but it was just sort of the idea came up and I wanted to say, hey, these ideas can work. You’ve just got to find the right hooks.

John Curran: So do you think ARIN should have such a program not based on the Internet2 one but one similar in nature to the RIPE-ness?

David Farmer: I think ARIN should have some sort of program. I’ll be thinking about this over the next couple of weeks on what the right parameters are, and I really think it would be great if we all went back and thought about what the right parameters are.

John Curran: Okay. Center rear mic.

Kevin Blumberg: Kevin Blumberg, The Wire. I love the concept, but I think we have to be careful that we’re not treading on the toes and adding a level of, where people think that you are the de facto standard, yes, they are now certified.

It needs to be a very basic, basic test that allows other companies and other organizations to say, yes, this company’s actually not only doing IPv6, they’re doing it properly, we’ve tested, we’ve certified, we’ve verified.

But at a more minimal level, as sort of more a fun tool, I think is appropriate. I think we have to be very careful that we don’t go into we’re now certifying people rather than anything else.

John Curran: I understand. You’re thinking more education and camaraderie?

Kevin Blumberg: Yes.

John Curran: Owen.

Owen DeLong: Owen DeLong, Hurricane Electric and ARIN AC. While it’s not exactly an ARIN program, we offer it free to the community, there is the certification program at tunnelbroker.net. And I’ll make a small shameless plug, since it’s a free service to the community. We’re not making money on it.

You can go there. You can learn about IPv6 and you can get a certification that shows you have properly deployed v6 and gotten this tall and managed to ride the ride.

For those of you that haven’t tried it, go get your sage certification on Hurricane Electric, and that comes pretty close to a logo program like we’re discussing.

John Curran: Can I ask a question about that, Owen? That’s focused on individuals. I remember when I was setting up my mail server to get through the stupid v6 hop to get mine.

Owen DeLong: Focused on anybody who runs a domain.

John Curran: But I think the program that Cathy was referencing in RIPE is more of an organizational, your organization is ready. I guess if someone from RIPE could talk a little bit about the RIPE-ness program.

Owen DeLong: You could easily do Hurricane Electric’s thing with an organization.

John Curran: Okay. That’s what I was asking. Center mic.

Bill Darte: Bill Darte, ARIN AC, Washington University. I think it’s a great idea to do something like this that produces an honor roll or something that just says – the terms that you use to label what you’re doing is as important in saying leadership or something like that. But I don’t think it ought to be onerous and representing your certification either.

John Curran: Okay. Center rear mic.

Geoff Huston: Geoff Huston, APNIC. I think on this honor roll stuff and so on just really doesn’t cut it.

I think you should actually look at the darker side and do the dishonor crap role. The reason why I say this is that Teredo doesn’t work, not because of local filters. It’s actually very standard UDP traffic. But the failure rate is 35 percent.

So the question we need to ask ourselves is, when these ISPs go and deploy CGNs, what will be the global failure rate of connections across CGNs? And who is going to measure that and track it and name it and actually understand how bad you’re making the Internet how quickly.

So when I look at this, I’m actually really interested in the behavior of connections across what ISPs are going to be forced to put into the field in the coming months and measure that. Because my suspicion is that what Teredo is telling us is that the connectivity success rate inside this network is about to plummet.

And it would be really good to have some measurements and some practical numbers to show to the broader industry about the penalties and prices they’re paying for not acting with some kind of alacrity on v6.

Rather than saying “good boy,” isn’t it a bit easier to say “bad dog”?

John Curran: Any other comments on this? Any other topics at all?

I do see from this high podium a little sunshine outside, and I will note that when we’re done with the open microphone session, I’m going to adjourn us. Some of you will go back to your hotel room and work, but some will find sunshine. So I’m going to close the mics soon.

Center rear mic.

Kelly Genessy: Kelly Genessy, Utah Education Network. I notice on your website that you no longer show the NS servers when you do Whois. Was that a decision that was made when you merged with ICANN?

John Curran: That last paragraph at the end, “when you merged with ICANN,” help me out with that a little.

Kelly Genessy: When you moved IN-ADDR.ARPA to ICANN.

John Curran: So there was a program planned for how to move.

Kelly Genessy: Not merged with.

John Curran: ARIN, for a dozen years, since ARIN took on the Internet responsibilities, that included, amongst other things, generation of the IN-ADDR.ARPA zone file. That was a somewhat unique Internet task that shouldn’t have been done just by ARIN. It’s really all the RIRs. We worked to get that handed off.

Now that ICANN is up and running and IANA function in it is stable and productive, we thought IANA would be a good place to have that done and the five RIRs agreed to move it to IANA. We agreed on a program plan.

When we did that, we sort of transitioned it to IANA.

Now, your question is why aren’t the servers visible on the –

Kelly Genessy: Before I could do Whois and actually visually see my NS server as it was hosted. If I did a Whois on my IP space, it would say your name server is NS dot whatever and NS2.

You no longer get that off the Web page. So you have to do do digs and things like that. And for our customers it’s a little harder for them to follow that. I don’t know if that makes sense.

If I did a Whois on the ARIN page in the past before the ICANN thing, you could actually visually see my NS servers.

John Curran: Mark, take it away. I have no idea.

Mark Kosters: Actually, we’ll sit down with you and show you how you can do those off the Web. It’s all there.

Kelly Genessy: I can do it. I’m just saying is there plans to get it back on the website?

Mark Kosters: It’s there on the website. We’ll show you how to do it.

John Curran: Microphones are open. You’ve got one?

Robert Seastrom: Rob Seastrom. I have my hat on as my day job. I work for Afilias. We run TLD name servers.

About three and a half years – I wanted to tell people about a little venture I had recently, and this should be very short.

About three and a half years ago there was RFC 4893 published. It involved 4-byte ASNs.

In the interim we’ve had Geoff here. We’ve talked about policy surrounding that. We handed them out by default for a little while. We got a lot of them handed back.

So I’m never one to give up a chance to be late to the party. I had an opportunity to request an ASN recently and I got a 4-byte ASN.

And I’m not going to name and shame the router vendor, but it was a little bit of an adventure.

We discovered that support for, while it was in fact a check box support, they said, yes, we support it, and that was true as far as it went.

It was not back-ported to the popular SP releases that service providers like to run.

The whole reason that we have 32-bit ASNs coming out there is we’re running out of 16-bit, ones which is the same reason we have the 128-bit IPv6 addresses because we’re running out of the 32-bit ones, and you would have thought whoever wrote the test harness would have tried announcing an IPv6 prefix out of a 32-bit ASN and tried to see if it created a 4 file.

And it did. And we were duly unimpressed. And just wanted to say it’s not over yet. Trust but verify with your check box support with your router vendors, because it probably isn’t what you think it is.

John Curran: Good public service message. Center rear mic.

Martin Hannigan: Martin Hannigan. Does ICP 2 apply to legacy address space?

John Curran: ICP 2 sets up the registry system for the entire Internet registry systems. It’s all numbers. Why?

Martin Hannigan: Good enough. Thanks.

John Curran: Sure. Any other questions?

Unidentified Speaker: RIPE NCC. There was a question about how it works in the RIPE NCC. Not the person directly working on this, but can give a little bit more information.

It’s based, yeah, like you said on a star system. In order to get the first star, it’s pretty easy. An organization, an LIR, has to have requested IPv6 address space.

So that’s where it all starts. And that’s just how to get the first, the way to get the first star. And as I said, a few people here said it stays on a level, I don’t want to say of a game, but it’s in a very informal way. So that people, it has brought almost a way of fun to get there.

So joint training courses. People are given advice on how to reach, how to get additional stars, which can be gotten, for example, if the address space is visible in RIS, the Routing Information System. If they’re reverse DNS set up, et cetera, et cetera, so step-by-step it’s done. And for more information there is the website which is ripeness.ripe.net where you can find more information, how it works, and who the LIRs are that have four stars.

So that it’s also a way of visibility for them to show themselves to the community.

John Curran: Excellent. Okay. Microphones are open. Still sunshine. Still time. Closing the microphones in just a moment.

Closing remote mics. Remote mics are closed. Microphones are closed. Thank you, everyone.

That concludes the open mic session. We’re done with our program for today. Tomorrow we will pick up with the members meeting.

Closing Announcements and Adjournment

John Curran: A couple of quick announcements for people. Coming up, okay, first, thank you for our network sponsor, AT&T.

(Applause)

ARIN question of the day: Tomorrow’s question, if you want to be videotaped answering this question: What was your favorite moment at this ARIN meeting. There you go.

Reminders and recap: Breakfast 8:00 a.m. tomorrow. The meeting starts at 9:00 a.m. The agenda is in your meeting folder or online.

We have reports from all the ARIN departments. The Board of Trustees and the Advisory Council. That’s it. Thank you, everyone. Enjoy your evening and we look forward to seeing you tomorrow.

(Proceedings adjourned at 5:00 p.m.)

Network Sponsor

• 

Social Event Sponsor

•