Call to Order and Announcements

Presentation (Read-only): PDF

Ray Plzak opened the second day of the ARIN XII Public Policy Meeting at 09:00 CDT. Announcements included thanking Server Central for its meeting sponsorship and ANet for partially sponsoring Wednesday night's social event.

ASO AC Election Results: Ray also announced Louis Lee as the winner of the election to fill the vacant seat on the ASO AC from the ARIN region. Louis Lee thanked the voters in attendance and gave a brief acceptance speech.

Policy Proposal 2003-12: IANA to RIR Allocation of IPv4 Address Space

Introduction: Einar Bohlin, ARIN Policy Analyst
Read-only Presentations: PDF

Presenter: Ray Plzak
Read-only Presentations: PDF

Comments:

• Questions:

  • How similar is this to the way allocations are currently made to the RIRs?

  • Will the information regarding these various rates be made public?

• Responses/Clarifications:

  • Special needs cases are calculated by taking the previous six month's allocation rate and multiplying it by 9. If that is the allocation rate, there is no special need.

  • There is no formal policy now and that's why this policy is being proposed. Currently, different justifications and questions are required for each allocation from IANA. The idea behind this proposal is that IANA should deal with the RIRs the same way that the RIRs deal with ISPs.

  • This policy will be an internal administrative process and will not be made public.

  • IANA lists ARIN's /8s on its website. However, when ARIN submits a request, IANA only reviews the /8s that were delegated or allocated to ARIN after December 1997.

• Suggestions:

  • The equal sign in the formula should be changed to less than equal.

Polling of consensus:

Question: Approve of Policy 2003-12?
Yes? 42 No? 0

IANA to RIR Allocation of IPv6 Space Discussion

Presentation (Read-only): PDF
Presenter: Ray Plzak, ARIN CEO

Ray Plzak announced that this is not a formal policy proposal, but an informal discussion and information gathering session. This topic has been previously presented at both the APNIC meeting in Seoul and the RIPE NCC meeting in Amsterdam within the past few months and will be presented at the upcoming LACNIC meeting in Havana. When the language is agreed upon by all four RIRs, this will be a global policy proposal to be forwarded to the ASO Address Council then transmitted to the ICANN Board for adoption.

This policy is similar to the IPv4 proposal, especially in the discussion and determination of available space. The policy will use the HD ratio to determine the RIR utilization rate.

General Comments:

• People want to have sparse allocation by regions, so it may be better to go from /20 to /18 in sparse locations.

• How the RIRs make allocations to the ISPs has nothing to do with the allocation that they receive from the IANA.

• Yes, it does. If we want to do sparse locations, then we want to have a larger block from IANA.

• That could be a factor. So what would you suggest?

• Slightly larger block of address space received from IANA each time and then allowing RIRs to do sparse allocation. But I would like it to happen only if all RIRs do it, not just one region.

• To follow up, you think the allocation should be larger now or should be larger if and when an RIR has a plan for sparse allocation?

• If and when it has a plan for sparse allocations. If and when all RIRs agree to this plan. I think we need to wait before deciding on IPv6 policy with IANA and to decide whether we want to do a sparse allocation or not.

• In the current environment, there is a method of getting an IPv6 allocation on the current allocation plan. I guess what I'm wondering is, given the current plans of the registry, is this a good allocation size or would you still recommend changing it?

• We could do with a larger space so RIPE, for example, won't have to go through and get an additional space.

• You would recommend doing a larger size now, A, so we wouldn't get multiple requests from someone like RIPE, and, B, because it would facilitate if we ever do sparse allocations in the RIRs, we have a block big enough already.

• One of the things you should consider in thinking about the size of the block that the RIR gets is how often you think the RIR should be going back to IANA to conduct business. IANA has its own things it has to do as an agent managing IP address space. So from auditing capabilities, a shorter time might be better than several years.

• What were the criteria that you used to pick the /20? Was that based on the utilization that you've seen over some period of time in the past, was it based on projected allocations, or was it a random number?

• It's probably a combination of all those, plus what I just said about trying to think about how often the RIR should go back to the IANA. The only real operational experience we have for a rapid allocation rate is what's been happening in the RIPE NCC meeting. But again they're allocating /32 for /29. If they changed their policy or if they went to a sparse allocation policy or something that may make a difference in how they would administer /20. The operational experience in the interim, we haven't been doing it as fast as the RIPE NCC has, however, within the first six months of the year we did allocate more at a faster rate. It's not to say as things change in the environment in our region that we could not begin to allocate even more space. Then, again, I can't speak for the exact experience of what the rates are in the APNIC region, but we're kind of at a crossroads of trying to determine what that should be. So it's like when we did the v6 policy in terms of 200 customers, a number had to be selected. This /20 number has not been really raised in the other regions. There's been thought it should be maybe /8. Some people think it should be /16. So I think that they could make a case for all of them. One of the things we did factor into this was a consideration of how often the RIR should touch the IANA so that there could be some kind of audit done.

• Once you set this number, how much effort would be required to change it if it turns out that the utilization rates go up more rapidly than you expected?

• What we're talking about here is a minimum size, if you will, as a unit. So it's just as RIPE now with the policy from the RIR to the ISP. There's a minimum size, but you get more by the original maximum amount. So if the allocation size was set at /20 and my 18 month projection was for 2.5 of those, I should receive three.

• It would be continuous?

• In that case I would say yes, they should be continuous.

Policy Proposal 2003-11: Proposal and Scope of the WHOIS Directory

Introduction: Einar Bohlin, ARIN Policy Analyst
Read-only Presentations: PDF

Presenter: Michael Dillon, Radianz, Inc.

Comments:

• Statements For and Against:

  • There is a requirement right now that all small allocations and assignments be listed. This is a good requirement because we can see how the ISP is doing reassignments and allocations. There are a number of reasons the allocation is not precise but it's still going to be useful. You are right to verify information, but to actually require not to publish it is a bad idea.

  • This is a really bad idea because there are so many other good reasons to publish the data. Sentence 2 is also a bad idea because I think keeping the process open is a good thing.

  • There are better ways to solve POC verification than simply deleting the POC data from what is published. Deleting the data is not a good way to make the data better.

  • I do not agree with your document. Being a small company, we only have so many people we can hire for abuse reports and complaints. If we take that information off of WHOIS, we're going to have to increase our abuse team.

  • I don't like it because it will increase abuse complaints that come directly to the company and don't go to the customer first where we have very capable customers handling those issues.

  • I don't agree with having to update POCs every three months. That's just too frequent.

  • If we are going to do it, I do think it's a good idea to update POCs, which I do regularly. Some people don't, so you have to take an action. Don't make it so quick and don't say you have to update every POC. It's a lot of time, a lot of work for something that didn't change.

  • Organizations that receive resources directly from ARIN should be required to publish this information in the directory. Some allocation assignments, reassignments that happen, anybody who doesn't have a direct relationship with ARIN but has a direct relationship with some other organization should be able to voluntarily do this and list information in the directory. We shouldn't require them because we have no way of enforcing the requirement. You can require the customer to do certain things if you want to and the customer can list certain things in the directory. If you don't have your customer's information listed in the directory, then what will happen is your entire IP block will be listed under your name and if there's any operational issues, we will contact you because you're the one we can get to and then it's up to you to decide what to do. Do you contact your customer? Do you unplug your customer? It's none of our business at that point.

  • WHOIS is an integral part of [ARIN's open process], and excluding that function in this policy is a bad idea. ISPs are not open processes. Generally they are companies. It is not clear to me that they need their entire dirty laundry aired out for the entire world to see. ARIN clearly does need that information. ARIN may need to make some of that in summary form available to extend the open process, but we need to make that distinction. The ARIN process is open. People do need ways to verify that. Maybe WHOIS is not the way, but that is the way it has been.

  • The intent really is to have someone who is willing and ready to act on information. That really has already been available by looking at the parent directory within the existing ARIN database. I think generally this is a bad idea by eliminating the majority of the hierarchy that exists today. All you're wanting is ARIN in its first relationship rather than dealing down with the suballocations; that those second tier customers may eventually begin to have a relationship with ARIN, have them supply this information, make sure it's current. Understanding the process is a good thing for them to learn what's going to be required when they evolve to the point they deal with ARIN directly.

  • I disagree with removing data from the directory. I believe the other proposal where we mark it as unverified is a better idea than moving information from a directory simply because a person is too busy to respond within 60 days.

  • Removing the data from WHOIS is inherently bad. Once it's gone, it's gone. Generally companies don't pick up and move their buildings. So addresses, organizational information is still there. I can hunt and peck and try and find someone else at the organization. The other proposal to mark it as potentially unreliable I think is a much better proposal than simply erasing it from the database and making it unavailable to anyone

  • You're trying to do too much with one proposal; the database verification method is covered in another proposal and an access method could also be a separate issue.

• Questions:

  • Is point 2 really another way of saying you want to remove unreferenced objects from the database?

• Responses/Clarifications:

  • When an ISP gets a block from ARIN, it's required to SWIP that information when it hands over those blocks to the customer, so it's not optional for an ISP to have that information about its customers in the database /29 or longer. When you go back to an ISP for another block of address space, you better have SWIPed all this stuff that you handed out. That's what they [ARIN] use to judge your utilization.

  • I'm not suggesting that ARIN no longer collect information in order to make decisions about allocations; ARIN should continue to do so. I am talking now about the information which ARIN publishes and makes public. I fully expect that ARIN will continue to collect the information through SWIP and through other means. This is not about that. This is about the information which is published.

  • SWIP submits the information to ARIN, which at this point automatically publishes it. If this policy were enacted, ARIN would no longer publish everything that was SWIPed, some of it would be kept private and some of it would be published.

  • Since you have a direct relationship with your customers, you can tell them a part of the deal is that you have to follow the rules here and list your information in the WHOIS directory and have it point to somebody who is ready, willing, and able to deal with abuse issues and you have to be able to do at least click on a URL and e-mail once every three months to verify your contact information still works.

  • Customers are lazy. They send [POC changes] to me, but they're not about to deal with ARIN because I am the ARIN liaison, and they are scared of ARIN and they don't want to deal with it no matter what. So to tell my customer you have to deal with ARIN directly in terms of what your information is, they're not going to be happy and I don't want to be put in that position.

  • I do use this information for research purposes. I much prefer that you mark it as unverified because even if that person is not there, if I know the organization, it's possible I could go to their webmaster, whatever their organization is I can find it in a different way. But as soon as the information is gone, I'm totally lost.

  • This is the amount of the allocation in this particular part of the country, these are the people who are getting it. I use it to map for geographic reasons when we're trying to do summaries, who is requesting sort of the locations on the net. These things, even though WHOIS is bad, are better than anything else.

  • This policy is really a way of saying that I want the contact information in the database to be certified that the people whose contact information is published are ready, willing, and able to communicate and act upon that communication. I want the database information to be somehow in some way verified and then certified.

• Suggestions:

  • It might be useful to accept all incoming entries into the database as not verified or without key. When they provide an X.509 key or they do their registration, that would be a way to, in Michael's words, certify. [Information] comes in as unverified data and only after they provide the key you say that's verified because the verification process occurs at key exchange.

  • The text "unreliable" might be construed as the person being unreliable. So "unreachable" would be a little better. I want to strike the text that says "within the ARIN region" because organizations and individuals might not be within the ARIN region at the time that you check the data. They might have moved out.

Policy Proposal 2003-16: POC Verification

Introduction: Einar Bohlin, ARIN Policy Analyst
Read-only Presentations: PDF

Presenter: Andrew Dul, proposal author

Comments:

• Statements For and Against:

  • This is an excellent approach to the problem. I have no objections whatsoever to this policy as written.

  • It's a bad idea for processes like this to be entered into policy documents because it ties the hands of ARIN staff. I would rather trust that staff would implement a reasonable process and then over time tweak that process to make it better rather than encapsulating it into a policy like this. It has things in it like ARIN should mark the POC as in process. That's reasonable to have in a policy, but the rest of it is too detailed.

  • It's a good future policy proposal. I want to actually be able to see verification of a particular resource. For example, I want to see if this e-mail address has been verified.

  • In general, I certainly support anything that verifies POCs. My concern is that ARIN has no way of validating whether a complaint is because they're unsatisfied with the response or they're simply trying to tie up my time and resources. In principle, I agree. I think it needs some work. I would encourage work to continue on it but wouldn't support it.

  • Even if it is verified within that year and somebody registers a complaint, it could go into a state where it then has to be re-verified. It's just a general concern, I don't like the principle of the idea of somebody from the external community writing that a POC is not available or is inaccurate and our experiences show it gets abused. That's just an overall statement.

• Questions:

  • If someone returns an e-mail and says everything's verified but you don't call the phone number to check that it works, it's not verified?

  • Has the presenter done any kind of an analysis of the resource impact on ARIN staffing?

• Responses/Clarifications:

  • I would like to see, for example, e-mail verified, phone number it doesn't say anything.

  • The idea of publicly displaying the status of a POC would be giving information to people that probably shouldn't have it. Because of the hijacking issues, making that kind of information publicly available might not be such a good idea. Making it internally available is a good idea and that is something we are doing. We have a status field for every POC in our database. It's unverified, it's verified, it's suspicious, it's suspended.

  • One thing that I put in here to try to combat the random customer from the other side of the world bugging you because they don't like you was the timeframe for verification. A year is very long in some people's opinion, and there's also a statement that says if it's been verified within one year, we don't go out and try to verify it again. So you at most have to verify it once a year.

• Suggestions:

  • It would be good to let staff have flexibility on the time frames for the stated changes in the database. The one year provision is a very reasonable compromise between minimizing the impact of organizations through complaint DOS, for lack of a better term, and verifying the Point of Contact information is reasonably up-to-date. Making it a little bit more generic in saying that "all reasonable efforts to contact" or words to that effect instead of specifying telephone, e-mail, whatever, would be good. I don't think we need to separate the verification flag out by contacting method. If you get a phone call back from somebody that says yes, that's my e-mail address. Yes, that's my phone number. Yes, all the contact information there is correct, that you can consider the contact verified. The same thing for an e-mail. So I wouldn't worry too much about that level of detail, but otherwise I think this is a good thing.

Policy Proposal 2003-5: RWhois Server Use

Introduction: Einar Bohlin, ARIN Policy Analyst
Read-only Presentations: PDF

• Policy Proposal Introduced - March 6, 2003
• PPML Summary:
  • Presented at ARIN XI
  • Current version Introduced - September 22, 2003
     
  • There were no substantive comments on PPML.

Presenter: Mark Kosters, proposal author

Comments:

• Statements For and Against:

  • I think you just need to work on the text. Other than that, it's a good idea and the main point of replacing RWhois by distributing information is a good idea.

  • I think this policy is premature. ARIN engineering made a presentation of technical deficiencies at the APNIC 15 conference in Taipei in February. It's that the code architecture is not good, referral doesn't work, and various other things. Since there is some work being done right now to fix the tool, I think that we really should wait until that's done before we put the policy through. Right now a number of companies are using RWhois because we want to have a distributed WHOIS service. But we are severely constrained and restricted by this poorly documented and awkward tool that we have to use in order to do it today. What I would really like to do is first implement the improved version and then I'll address all of these issues with that new, improved version, which will make it easier for me to address all of these issues in the policy.

  • A lot of the reason these issues addressed in your policy and a lot of the reason these issues exist is because we are struggling to function with this bad tool.

  • We've got a tool. It's out there. It's in use. We've got operational requirements. This policy sets forth operational requirements for us to be able to use the tool that exists today and whatever tool gets to be played in the future. And I think it's got to have those operational requirements specified in the policy so we can actually use whatever tool today and in the future to get the data we need.

• Questions:

  • RWhois has been attempted to be shot in the head repeatedly over the years and it continues to thrive. There is apparently another proposal or a series of proposals to replace it on the hoof. Should we be encouraging people to adopt RWhois if there's something else that's relatively imminent?

• Responses/Clarifications:

  • The actual text says RWhois, but it's really meant to say distributed information service. So whatever is to replace RWhois, the same policy would apply. This is an attempt to say if you put up one of these distributed information servers, you have some requirements that you need to follow.

  • This policy is not premature because it's already fielded and it has guidelines for those who have already fielded their distributed information services.

Polling of consensus:

Question: Approve of Policy 2003-5?
Yes? 24 No? 5

Hijacking Report

Presentation (Read-only): PDF
Presenter: Leslie Nobile, ARIN Director of Registration Services

Leslie made a presentation about the recent IP address space hijackings.

• Hijacking is defined by ARIN as "Individuals targeting mainly legacy IP address blocks to make unauthorized changes to registration records in WHOIS. The WHOIS data then inaccurately reflects this false information and gives the illusion that the individual now has some authority over the resource records. Affected resources include IP addresses as well as AS numbers."

• Hijacking misleads network operators, compromises the WHOIS database, creates liability issues, increases staff workload, slows response times, and increases staffing and legal fees

• From April to October 2003, 110 cases were opened: 11 cases were found to have no evidence of hijacking, 84 cases were closed, and 15 cases are still pending

• ARIN's actions:

  • Identified patterns used by hijackers to uncover unauthorized database changes
  • Monitor “hijacked” list
  • Research every reported or discovered hijacking
  • Document and track every case
  • Working with law enforcement agencies
  • Developed/modified processes and procedures
  • Developed new database “status” attribute that can lock down records
  • RIR Coordination

• ARIN is not:

  • Reporting every incident to law enforcement agencies
  • Providing investigation details to the general public due to non-disclosure practices

• To help ARIN combat hijackings, ensure all of your and your customers' Org and resource records are updated and use stronger authentication when available

• Several possible actions for policies and procedures, database solutions, and legacy space were discussed

General Comments:

• Requiring tax ID and raised corporate seals is a wonderful idea for your customers who are incorporated. However, there are at least three, maybe two allocations in the database that I know of personally that are individuals that don't have a corporate seal and aren't particularly interested in providing a Social Security number to ARIN.

• I think this is a really good idea because it removes a lot of the arguments that we have right now between people who have legacy records and can't see why they should have to worry about paying money long after they helped build the Internet versus the people who are getting IP addresses right now and paying money into the registries and working hard and have no idea why these old geezers should be allowed to freeload. Neither of these parties are in the wrong. They both exist. There's no way around that. This is a way of removing any cross subsidy between, and I'm strongly in favor of it and I think you all should be too and I can argue with anybody that thinks otherwise on my own time.

• I also agree -- it's going to allow ARIN to lock down all the old records and basically allow any changes unless they want to play by new added rules. ARIN has to have some financial records to prove what kind of company it is. It's going to solve quite a bit of problems trying to pin down whether it's a valid company or not.

• I was talking about the transparency issue and the historical record, and I really think that would go a long way for its people being able to tell ISPs whether the information is to be taken at face value or not. Obviously if people were to look at the historical information on my personal blocks, you would see a few address changes, same person, you know, across multiple changes as the POC and assume that that would play the reason of the evolution of the corporation or individual. And I think that would be a huge step in the right direction. It could be a step we do retroactively. The question is do the data exist?

• I am concerned that legacy holders may have that particular snobbish attitude of we're the old guys and we were here long before you, if we move them unilaterally to some legacy database, they might object to that as well. I would encourage ARIN to spend a little bit of their phone time talking with the legacy holder as opposed to just tracking down hijackers to invite them to join ARIN and to participate in the current process and inform them that one of the choices we have is that we expect to move you into this other thing that's going to be relatively skim, pretty much static, and we'll just leave you there until you decide you want to come out of your suspended animation and join the real world, and when you do, here we are. There ought to be a dialogue with the legacy holder before we move them.

• It strikes me that this conversation about moving legacy address space into legacy databases is sort of another variation of the previous discussions we've been having on verification of data in the WHOIS database. I don't think it should be separated from that. I don't see any difference between the address space that I acquired a few weeks ago from ARIN and a legacy block that has up to date contact information and whether that actual organization is a member of ARIN or not. If that contact information is up-to-date on that legacy block, it really isn't a legacy any more. I think what we're really talking about here is the set of address blocks that don't have up-to-date contact information. We don't know who they are, what they're doing, where they live, et cetera.

• I think from a lot of people's point of view, the difference is whether or not we're paying fees to ARIN. Whether or not they are contractually obligated to ARIN and whether or not they have signed a contract acknowledging that they do not own the address space they have; that there are a lot of people who have address space that they received prior to joining ARIN under an informal agreement to book something like it being given to them. And there are a lot of people who do not want to sign a contract with ARIN acknowledging that that is not the case. And so this is the way of removing any financial burden of supporting those people from the regular ARIN membership.

• I believe that if ARIN is responsible for these addresses in any way, shape or form, keeping track of them or anything else, legacy or not, we should all have to play by the same rules. They should have to pay, they should have to keep track of all their stuff, and I could bet there's many people that won't agree with that.

• To me whether it's in a separate database or whether it isn't, I'm not so concerned about that. But I do think it provides a wonderful opportunity to try to contact legacy folks and say, "These issues are out there and frankly we're not going to be able to protect you as well if you aren't someone who we can authenticate in this process." So I think it's a great opportunity to go out and challenge those folks to be involved.

• As someone who holds blocks in both categories, I would be pretty upset if I got told that I suddenly had to start paying ARIN for that legacy block. Even though it wouldn't affect me financially, ARIN doesn't have any real authority to do that. There's no real contract between me as the owner of that block and ARIN that allows them to suddenly tell me I'm going to start paying them for it or anything like that. And I think it would meet with some pretty strong legal challenges with a lot of other people in a similar situations. Hijacking is an issue. Hijacking is an issue that is taking a lot of ARIN staff time, and I don't have a problem with that block being moved to a legacy registry and having the choice of paying fees to get it into the registry that I can update and that ARIN will spend time on. I think it's perfectly reasonable for ARIN to move those into some place they don't have to deal with.

• To clarify the options that were on one of Leslie's slides:

  • No. 1, that this be maintained in a way that a lot of Internet resources are on a voluntary basis while trying to minimize the workload. So this is the everything is completely static but there are no fees basis. People who did not respond to ARIN's solicitation to join would then be moved off into a registry which has no customer service and charges no money. If they wanted any customer service, they could go join ARIN and ARIN could pull their records out of the RLR and into the ARIN database and make the necessary changes.

  • No. 2 is one in which the legacy registry would, in fact, operate as a regular registry and be able to make changes on a fee-for-service basis. There would be no charge for holding the records in the legacy database but there would be per service charges, say, hypothetically, $50 if you wanted to change your name server record. And this is a much more difficult task because it involves spinning up a large organization that has to do more, it has to do all the sanity checking request. It does not do as much to prevent hijacking as a static registry would.

RTMA Working Group

Working Group Chair and Moderator: Cathy Wittbrodt

• Asked attendees to think about the future of the RTMA working group and send comments to the RTMA mailing list

• Suggested disbandonment if there is nothing for the group to do

"Miscreants, Hijacking, and Bogons - Oh My!"

Presentation (Read-only): PDF
Presenter: Rob Thomas, Cisco/Team Cymru

Rob presented a discussion of a wide variety of network security issues. Security incidents have become a daily event for Internet Service Providers. Attacks on an ISP's customers, attacks from an ISP's customer, worms, BOTNETs, and attacks on the ISP's infrastructure are increasing in frequency.

He went on to discuss bogons; a bogon prefix being a route that should never appear in the Internet routing table. A packet routed over the public Internet (not including over VPN or other tunnels) should never have a source address in a bogon range. These are commonly found as the source addresses of DDoS attacks.

In addition, he discussed the “miscreants” who are becoming increasingly sophisticated with their technology and methodology. Because spamming equates to big money, they will resort to almost anything to get what they need and want from the Internet and its users and operators.

Policy Proposal 2003-4: IPv6 Policy Changes

Introduction: Einar Bohlin, ARIN Policy Analyst
Read-only Presentations: PDF

• Policy Proposal Introduced - March 6, 2003
• PPML Summary:
  • Presented at ARIN XI
  • Current version of the proposal is the same text that was presented at ARIN XI
  • There were no substantive comments on PPML

Presenter: Thomas Narten, IPv6 Working Group Chair
Read-only Presentations: PDF

• Some follow-up discussion within AC

• Proposed the abandonment of the current proposal as a whole, but pursue parts of the policy proposal through global-v6 mailing list or within ARIN as appropriate

  • Clarify definition of “organization” - Follow up on global-v6
  • Waiver of criteria of 200 sites - Follow up on global-v6 (address underlying issue)
  • Waiver of fees - Submit a separate proposal on just this (if necessary) to ARIN
  • Micro-allocations - Drop this (global-v6 would be place to pursue this first)

Comments:

• Statements For and Against:

  • The AC reached largely the same conclusions as Thomas. There's no real issue from our [the AC's] point of view with any of this.

  • I would like to understand the reason for the waiver. It seems to me that is actually the kind of thing one would want to do through a regional policy because the situation in North America is quite different from the situation in Asia-Pacific. Where in Asia-Pacific and even in Europe there is a lot of take up and they may not feel the need to promote it in any way.

  • This deep into the process, starting the whole process over again may cause too much of a delay to achieve the desired result, that is to encourage deployment of IPv6.

• Questions:

  • When do you intend to submit a proposal?

  • Is it possible to break up these four parts or the three sections and address them separately and maybe fast track it and say let's get this part accomplished?

  • What work has been done in the past six months among the other RIRs in regard to changing IPv6 policy?

• Responses/Clarifications:

  • The motivation for waiving the 200 sites was that many felt getting 200 sites within two years was such a high bar that nobody could meet it.

  • I would like to encourage you to continue doing your experimentation and not to regard the criteria as they currently exist as an impediment to your being able to do that work. I don't think that it was intended to function in that way, and we will certainly do what we can to pursue this as quickly as we can.

  • This is a different direction, but in the APNIC region, my understanding was the 200 figure was discussed in one of the issues. And where they're heading at this point is to clarify and add a discussion aspect to documents because there was originally pressure about what was written. Now they've started talking about the fact that there is much less of a sense they need to change the policy than get people on board with what they're doing.

  • Paul Wilson - APNIC - I was involved in the drafting of this policy and that was actually one of the intentions stated exactly, that there would be a transition to v6 by existing networks at least and the address space used should be recognized. This was discussed in the APNIC meeting recently. There were quite a number of people in the audience relieved to hear that explanation, and it was also agreed that we would be writing a document to clarify that part of the document.

  • Anne Lord - APNIC - We had no substantial proposals or changes to the existing policy. What we had at our last meeting was a review of some of the problem areas and some of the areas where there had been some misunderstandings and that actually included the criteria for the 200 sites. And what we had was a proposal for an information document, which basically takes out of the existing policy document a lot of the explanations and puts that into a guidelines document that gives explanations for why it was 200 or what sort of examples do you need to actually qualify, and just basically creates a guidelines document that's based on our existing IPv4 guidelines document.

  • Leo Vegoda - RIPE NCC - We haven't had any concrete proposals or changes to the policy in the RIPE region. We've identified a number of problems we have with the policy internally where we can see some amendments would probably be useful for people but generally it's worked very well because I think we made over 250 allocations in just over a year. So it seems to have been a fairly successful policy.

  • Raúl Echeberría - LACNIC - We have our working group working to have a proposal to be discussed in our next meeting. The formal proposal will be published in the first week of November, I think the 5th. But as far as I understand, as a working group we propose to remove the 200 members. The idea behind that is that whatever could be the number included in the policy in no plan saying that an ISP in Latin America will do 50, 60, 70 allocations in two years.

  • I believe we should move forward with an ARIN-only policy as coordination between the RIRs would extend the process too long.

  • The problem here as I see it from the AC point of view is that when it comes to IPv6 there is a frightening amount of ambivalence. We have passed proposals in the past when there was no objection but there wasn't any clear support either and we've run into problems doing that, so it's not the AC's job to move ahead if there's no objection. A proposal needs to happen when there is a clear mandate from the community, and we're not seeing that. We see people saying we need to do something, but there's no activity on the mailing list and once we leave these meetings, I'm willing to bet we're not going to be moving forward. Just doing something because it's there is not the right way to go. We've done that kind of thing before. So if people want an IPv6 policy, we need people who are going to participate and who are really going to help out in the process because there's not a lot of experience out there in IPv6 and there are not a lot of people who feel they're authoritative. I don't know where to start, but we need more participation.

• Suggestions:

  • It would be helpful if there were a backgrounder that describes how we got to 200 sites in the first place. If we're going to waive it in favor of something else, I would like to know why 200 was picked in the first place. This would clarify any future discussions about this policy moving forward.

  • If we really wanted to promote IPv6, I think the sensible policy should be, if you have an IPv4 allocation from ARIN, you get one IPv6 block. You may have 400 IPv4 blocks today. You get one v6 block. Anybody who has a network eventually should be running IPv6, so anybody who has space ought to be able to get it.

Polling of Consensus:

Question: Should the ARIN AC continue work on proposal 2003-4?
Yes? 29 No? 3

Policy Proposal 2003-10: Apply the HD Ratio to All Future IPv4 Allocations

Introduction: Einar Bohlin, ARIN Policy Analyst
Read-only Presentations: PDF

• Policy Proposal Introduced – August 21, 2003
• PPML Summary
  • 9 posts
  • 5 different people
  • Won’t this waste more IP space?
  • This is complicated, why not just say 50%?
  • Terminology: Let’s get rid of the words “allocate” and “assign.” What is a “utilized net,” what does that mean?

Presenter: Michael Dillon, Radianz, Inc.

• HD ratio is a different way of setting a threshold rather than setting a fixed hard threshold of 80 percent.
• Areas changed by proposed policy:
  • When you apply for a new allocation you have to report on your entire address space and calculate the host density ratio
  • Includes host density ratio and picks a couple of numbers similar to the way
    the current policy has picked 80 percent as a magic number
  • In our current policy we don’t really tell people how to calculate utilization,
    this proposal requires that you calculate the HD ratio

Comments

• Statements For and Against:

  • The acceptance of this policy would negatively impact smaller ISPs. It might be okay for the larger ones.

  • I would not object to this proposal if it was implemented for only the large organizations.

  • This is generally a bad policy for a couple of reasons. It is overly complex and it requires a fair amount of effort to compute those values for your space.

  • My major opposition to this is that typically when you get to a certain utilization threshold, 80 percent or higher, of an older block, then more than likely the utilization of that older allocation is going to stay at least that high or continue to grow. So for that reason, I really would not like to see this adopted as worded.

  • Then we should simply change the thresholds. I think this policy is a bad idea.

• Questions:

  • Are you pointing out the fact that this specifies addresses whereas historically the 80 percent has been calculated by the SWIP blocks to customers? In particular, once a block is SWIPed, it's considered utilized?

  • What is the problem you're actually trying to solve here?

  • Can you define what 'all previous allocations' means?

• Responses/Clarifications:

  • There's a clear definition of how we compute utilization. Even though I don't believe it's true utilization, it's what you SWIP to a customer and assign that it's utilized, and that's really simple for people to understand. And I've talked to a lot of people about this and the HD ratio is way more complicated.

  • Richard Jimmerson, ARIN Director of Operations - I want to make a point of clarification, and that's that the [current] policy does state that it's 80 percent of all previous allocations. It is true that ARIN does focus on the most recently allocated block of address space, however we do on occasion go back, not every time, but do an audit of previous allocations before that.

  • The HD ratio policy is saying that instead of using a fixed threshold, no matter what the size of your address block, the threshold would now be a curve where the threshold reduces as the size of address block increases. If we do set this as a policy, we might want to be very careful about the exact value and adjust it a little bit to make sure it doesn't penalize the small blocks.

  • Yes, I realize you can do it in a spreadsheet, but, frankly, I can do most of these calculations in my head for the blocks I had. I think that it does penalize smaller providers whether that was your intention or not, and further I think as your blocks get larger it actually provides more and more incentive to be less and less efficient.

  • Right now there are companies who have older address space and they're reserving this, stockpiling it. And they're stockpiling it because when you get to the point where you have to apply for new addresses and you can get them more quickly from ARIN if you have these older blocks. The other issue is that it is known that larger networks do have larger overhead and that overhead is more than the 20 percent that is allowed for in the rigid fixed threshold that we use today.

  • Some people have made the assertion that this would unfairly impact people with smaller allocations so I did some calculations and discovered that actually this density number is about 65 percent of utilization on a /24.

  • Paul Wilson - APNIC - This is a very interesting proposal. I confess I had something to do with it when presented at APNIC. In APNIC, ISPs tend to worry about having a hard time in meeting 80 percent utilization. So this was driven by a clear need in our membership to make life easier only to the point of being reasonably easier for larger ISPs. The whole basis of the HD ratio is as your address space gets larger, your overhead increases. This proposal was an effort to take that into account. So while it doesn't make life easier for smaller ISPs, it doesn't make life any harder for smaller ISPs. And going back to my own experience in ISPs and their experiences, I've never heard a single complaint from a holder of a /20 that they can't make HD utilization.

  • It's worth pointing out that the HD ratio needs to be computed exactly once for your entire allocation. It's not like you're going to be calculating the HD ratio hundreds of times a day. It's only going to be every three months when you get a new allocation. Thinking of it that way might get rid of some of the complexity concerns.

  • What I have understood is that the problem can be solved by using the HD ratio but can also be solved adjusting the 80 percent threshold or just by adjusting it for specific classes of customers.

  • It's trying to change that percentage threshold. And how do you change the percentage threshold? This sliding scale calculated by the HD ratio which is part of the v6 policy seems like a reasonable way to do it. Whether or not we actually enshrined HD ratio in our policy for IPv4 or whether we use HD ratio in calculating a set of percentages for the table and then destroying the table, it doesn't matter. It's the same -- the principle is the same of having this sliding scale.

• Suggestions:

  • I would urge you to consider adding a very long lead time for phase-in of this policy so that the companies have time to be able to make appropriate plans.

  • Maybe we ought to look at the classification of small, medium, large, and extra large and look at a different percentage of ratio for those, which I think is the intent that you mentioned. I would suggest we move forward with looking at a means of scaling the 80 percent threshold for larger providers but at the same time not adopt this specific policy because it does seem to be overly complex.

  • I think it's a little unnecessarily computationally complex. I think it would be good to maybe have a table that said if your block size is X, you need to achieve Y percent of utilization and perhaps moving that along HD threshold as you specify in the guidelines, is a good thing, perhaps it's not.

  • I gather that one of your justifications for this proposal is that large organizations have more overhead in their IP blocks, therefore they're going to need more time to make their request before they get a hundred percent saturation on their blocks. If that's the case, maybe it's addressed underneath a different proposal, 2003-13, where the time frame changes from three months to six months.

  • While I like the policy in concept, what is missing here for me is the impact data. What was greatly lacking from the presentation today is simply a graph for a /whatever and here is what it translates into as a percentage. Along those same lines, what would this really change in terms of number of IPs given out. We don't know what the effect of this would be other than making life easy for some people, which is good. But how do you quantify the effect on IPs being allocated and that's just missing.

  • I would like to see ARIN undertake a survey of the membership to see what they’re using to manage IP addresses on their site. If nothing else, to identify the list of the possible products that one should be looking at or open source tools that one should be trying out.
    

Polling of Consensus:

Question: Should ARIN look at different thresholds for utilization for organizations with different amounts of address space?
Yes? 43 No? 19

Policy Proposal 2003-13: Six Month Supply of IP Addresses

Introduction: Einar Bohlin, ARIN Policy Analyst
Read-only Presentations: PDF

• Policy Proposal Introduced - September 12, 2003
• PPML Summary
  • 1 post
  • Good idea

Presenter: Michael Dillon, Radianz, Inc.

• This policy is meant to address the paperwork and planning overhead types of issues
• Companies will work on a slightly longer cycle once they are familiar with ARIN processes

Comments

• Statements For and Against:

  • This is a good idea. In my opinion, this proposal will create even better routing to the HD ratio for ARIN, which is positive.

  • I actually like this one. I think that it's long overdue.

• Questions:

  • You previously talked about a proposal dealing with HD ratios. Do you still think you need the proposal?

• Responses/Clarifications:

  • This is intended to help the people inside the member companies who have to handle the process of applying for addresses and then getting them deployed internally by giving them a longer planning cycle to work with.

  • I just want to comment on the last speaker. They're very separate proposals. And the first proposal is really: does ARIN agree to accept physics? Physics says that the bigger the address space, the harder it is to manage it, the more efficient you're going to have assignments and the former proposal was to agree, yes, that's real. This is completely different concept and totally unrelated.

  • I happen to be a physicist, and I think the second proposal is actually much more about reality. This is what happens in real life and that makes more sense.

Polling of Consensus:

Question: Support Policy 2003-13?
Yes? 79 No? 0

Policy Proposal 2003-14: Remove /13 Maximum Allocation

Introduction: Einar Bohlin, ARIN Policy Analyst
Read-only Presentations: PDF

• Public Policy Introduced - September 12, 2003.
• There were no comments posted to Public Policy Mailing List (PPML) regarding this proposal.

Presenter: Dan Alexander, Comcast Cable Communications

• Further described the intent of the policy
• Asked for confirmation from the staff of the other registries present about that lack of similar restrictions in their regions

Comments:

• Responses/Clarifications:

  • Leo Vegoda - RIPE NCC - We don't have a maximum allocation size

  • Anne Lord - APNIC - We don't have a maximum either in our region

  • Ricardo Patara - LACNIC - I think LACNIC has a maximum /13

  • Alec Peterson, ARIN Advisory Council - I could see this question coming, so I'll try to address it right now. The /20 statement in there, in the event that the minimum allocation size is changed with respect to the 2002-3, we will work with the author of this proposal so that there is not any sort of conflict with respect to the minimum allocation size.

Polling of Consensus:

Question: Support Policy 2003-14?
Yes? 79 No? 0

Policy Proposal 2002-2: Experimental Internet Resource Allocations

Introduction: Einar Bohlin, ARIN Policy Analyst
Read-only Presentations: PDF

• Policy Proposal Introduced - September 22, 2002
• PPML Summary:
  • Presented at ARIN X
  • Revised version presented at ARIN XI
  • Current version is the same text that was presented at ARIN XI
  • There were no comments posted to Public Policy Mailing List (PPML) regarding this proposal since ARIN XI

Presenter: Suzanne Woolf, ARIN Advisory Council

• Raised three questions for discussion:
  • Do we need this proposal at all? RIPE NCC and APNIC have similar policy but does ARIN need it?
  • Discussion in Memphis included concerns from the IETF about liaison with IETF to vet experimental proposals. Is requiring an RFC a good way to do this?
  • Discussion in Memphis also suggested a need for inter-RIR cooperation in this proposal to observe any unforeseen global impacts of an experiment. Does the staff have suitable mechanisms for implementing this? Is this enabled or enhanced by the NRO’s coordination mechanisms?

Comments:

• Statements For and Against:

  • Current policies allow you to get space if you need it. We don't need a special policy.

  • I think this is an important proposal for not necessarily obvious reasons. Currently, in theory, if the IETF passes an RFC that says an experiment needs address space the IANA thinks they might be able to allocate that. I think this proposal clearly and unambiguously says that's an RIR function. And I think that's a good thing to do. It also says clearly that the addresses can be reclaimed at the end of the experiment which nothing currently states. So I think it's an important proposal.

  • I would have to echo those sentiments. I would point out that there is a resource allocation term and renewal that is well defined. There's also a number that the members will have to decide, and that is a suggestion in this policy that the allocation fee should be not the same allocation fees that are in place, but that it should be sufficient to cover the administrative cost of this experiment. So clearly there are some differences between this and the existing policy, and I'd like to voice support for this.

  • I like this because it dovetails nicely with the ARIN mission statement.

  • I think it's really a good thing for us to accept this policy partly based on the precedent that APNIC and RIPE NCC have already accepted this policy.

• Questions:

  • Is there a specific proposal on what type of RFC? You mentioned the RFC consensus process which, for example, an experimental RFC doesn't have to do.

  • If I restate that, you're saying we have existing flexibility to do this?

  • How many allocations have been made under the APNIC policy?

• Responses/Clarifications:

  • The wording says "IETF consensus" provided by 2004. My understanding and I believe that the words basically mean you have to get an RFC published if it were experimental.

  • Experiments are coming from the IETF. I still don't see why the Regional Internet Registries like ARIN or APNIC should be involved. I just don't see why it has anything to do with ARIN.

  • Just a very brief point of information. I know of at least one person with NANOG who is not at this meeting and historically he was very interested in doing experiments which required access to large address blocks that were historically routed and then returned. I think he was referred back here but I would like to make people understand there are real experiments that are interested in address resources to do things, and this is not an issue that has no interest in the wider community.

  • Richard Jimmerson, ARIN Director of Operations - It is my understanding that a lot of these experiments would not include address space to be used on the Internet and we don't really have a policy that says we can make allocations to organizations who are not routing the space on the Internet. We don't really have a policy that tells us we can't do that, but it's not our normal practice to make allocations to organizations that aren't going to be routing the address space. We don't have anything that talks about experimental in our policies right now.

  • Anne Lord - APNIC - A version of this policy has been in place in the APNIC region since December 2002. And accompanying the proposal was a paper explaining the motivation for the policy. One of the motivations was that currently there was no way to get resources for experiments. There also existed the need to provide a framework for experiment allocations that was actually different than the current way of getting address space.

  • Anne Lord - APNIC - In the year or so we've had the policy in place, we've had one application and in the process of the dialogue with the applicants, they found that they didn't really fit the policy. They decided to apply for space under other criteria in that case. We've been advised recently that there's some universities that might apply in the near future.

  • Leo Vegoda - RIPE NCC - We passed a version of this policy in the RIPE region. I think we started using it in the beginning of 2002, and we've had one assignment under this policy.

  • The university community is going to have increased interest in this kind of option for research in the area of network telescopes, which is just getting off the ground and uses chunks of address space allocated temporarily.

• Suggestions:

  • IETF consensus, that's potentially a concern. I think it needs to be clarified. There has been a great deal of discussion in certain parts of what people should mean by the phrase RFC consensus defined in the RFC. So I would suggest that the words not refer to that specific RFC and say exactly what is meant by consensus.

  • I think it would be not a bad thing to clarify in the policy that this could never turn into a permanent assignment. And as the RIPE NCC experience shows, this is not something we're going to have a lot of people flocking to the door for, so the processes the staff will have to implement are probably not all that much of an onus.

Polling of Consensus:

Question: Support Policy 2002-2?
Yes? 55 No? 1

Internet Resource Policy Evaluation Process (NEW)

Presentation (Read-only): PDF
Presenter: Scott Bradner, ARIN Board of Trustees

Scott presented the proposed revision to ARIN's policy evaluation process. Highlights included:

• Existing process document in use since April 2000; ideas for updating document discussed at ARIN XI and discussion continued on PPML

• New process draft published on October 8, 2003

• Policy process now includes better checks and balances to meet goal of having an open and transparent process

• AC conducts initial review of suggested proposals, petition-based process to push policy proposals forward without Advisory Council support

• A second review by the AC after discussion at a Public Policy Meeting

  • If rejected by AC, a petition process is available to have the Board consider a proposal

General Comments:

• You did not mention anything about suspension of the policies.

• To remind folks, if new information reaches the Board after a policy has been adopted, the Board can suspend the new policy pending a discussion in a Public Policy Meeting.

• I think it was implicit but not explicitly stated in the very first line that if the AC thinks that two policies are much the same and need to be converged, you stated that the AC would try to work with the authors. But if they chose not to they could go forward separately at that point.

• They could go forward by petition.

• One other point was that you mentioned if a policy got to the Board and the Board rejected it, that they would have to express a reason for doing so. [Scott replied in the affirmative.] But you did not state that if the AC chooses not to forward something, that they didn't need to express why they made that decision. Did you leave that out on purpose?

• No, that should be in there.

• My concern is that I would hope that we could clarify Option B. Where there's a general consensus but we just need to make some minor wording changes, that rather than to kick it back so it has to come back to the Policy Proposal Meeting six months later, that we have a way to go ahead and push once they clarify this, that they can go ahead and do the last call for comments, and that's not clear.

• Substantive changes require another cycle, editorial changes do not. There's got to be a significant issue to kick it back for six months.

• I would like to say this is a big improvement [over the current process].

• You make provisions for combining proposals but you make no provision for deciding the pieces of a proposal don't necessarily need to have their fate tied to each other, and I think it would be a good thing to split the proposal sometimes.

• That would be a good addition.

• I like this. Are "organizations" the correct filter to use? What about "members?"

• This is something that came out of the discussion last time that we want a low but real threshold to escape the AC's embrace for the first time and a reasonable threshold the second time. This is a Public Policy Meeting so it's not a member's thing, so it can't be members and it can't just be five people from the same company as the proposer supporting it.

• Can you define what an organization is? [Scott affirmed that would be a good thing to include.]

Polling of Consensus:

Question: Support proposed Policy Evaluation Process?
Yes? 66 No? 0

Open Microphone

Moderator: Richard Jimmerson

Richard Jimmerson opened the Open Microphone session saying that if there’s anything to be discussed that is not on the public policy agenda, this is the time for those issues to be brought forth.

General Comments:

• Lea Roberts, Advisory Council member - I would like to request our chairman to get a little more direction for the AC on the IPv6 policy proposal [2003-4].

  • The following questions were asked by John Curran of the attendees

    • How many people believe the micro-allocation clause is an important element of IPv6 micro-allocation policy?
      For: 5
      Against: 28

    • Should ARIN suspend fees for IPv6?
      For: 62
      Against: 1

    • Is waiver of allocation criteria important for early adopters of IPv6?
      For: 45
      Against: 2

    • Should the AC, in preparation of the final IPv6 allocation policy, look into the definition of LIR?
      For: 5
      Against: 7

• Sarah Garfinkel - I think the problem with the last discussion was we had too many different pieces in this policy, so we couldn't get any agreement and I guess now we're trying to break it up. Maybe we should in the future have much smaller bits in different policies so we can get it through in a timely manner rather than having big arguments like this.

• John Curran - That appears to be good advice. Getting something through is easier if it only changes one thing at a time. The counterpoint is IPv6 is a fairly new playing field, and we have to lay down pretty much a set of rules at once, so the first time through is expected to be problematic.

• Owen DeLong - As I understand it, ARIN actually does, at some level, track contact reliability, for lack of a better term, in the existing WHOIS database. I understand the desire not to publish that at this current time due to the hijacking issues and such, but I would also like to encourage the ARIN staff to consider publishing it, as it would help a lot of us that are dealing with this stuff on the outside deal with some of the hijacking issues.

• Izumi Okutani - JPNIC - I would like to know what you all think about making an allocation to IPv6 closed networks. In Japan, this ISP provides its service to its customers, connections to its customers, but they would like to provide another service using IPv6 networks to those subscribers but it's closed, so they use this ISP's infrastructure in a closed IPv6 network, and they have over 1 million customers for this, so it's not possible to assign individual and contiguous /48 to each customers, so they have requested for an allocation. And the current policy is quite ambiguous if such allocations can be accommodated to closed networks and I'm interested to know what you all think about this.

• Michael Dillon - When you say closed networks of these millions of subscribers, do any of them actually have their own networks? Is there a closed network of companies which have their own networks?

• Izumi Okutani - JPNIC - I think some do, but I think some can be home users.

• Michael Dillon - My company has a global IP network in 20 countries worldwide and those countries are the ones in which the global financial service industry is focused. We have roughly a thousand customers. All of those customers are companies and they all have their own networks. On these networks some of them use IP address networks because they're obviously a private network. Some use unique registered IP addresses and our network interconnects them all. We don't pair with anyone. It's a closed private network for this group of companies to do various applications. But because our network isn't a private network really in a sense of IP space because it's shared by many companies, networks, we cannot use RFC 1918, we must use global unique IP addresses. That's why I'm here, because we have a large allocation of addresses from ARIN for this purpose and this sounds similar to what Izumi has described.

• Michael Whisenant - I just wanted to mention that with the use of Level 2 VPN, you can indeed have separate networks on your network that are using the same RFC-1918 address space. You can do it on our network as well. So in the aspect of getting a closed network can have private networks it also can have public networks is one I want to point out for clarification. It's not a requirement to have public IP address space on a public network.

• Leo Vegoda - RIPE NCC - We had the same problem with the IPv6 policy being ambiguous. I think definitely the text needs to be improved because it's ambiguous at the moment. It's not really a hundred percent clear what the policy is, so people need to decide what the policy is and then write that down.

• Thomas Narten - My recollection is this particular issue is something we did not consider in time. It does need to be discussed and dealt with.

• Cathy Wittbrodt - I personally believe that people should get to use public address space for this because it's a huge barrier. But I was wondering if maybe we could take a straw poll of people who think this is a reasonable thing to get public address space for because we've been churning about it two days now. It's really a problem for the consistency so maybe we can see what people think.

  • A straw poll was taken with the question: "How many people think assigning public address space for private applications is important to look into?"
    For: 70
    Against: 2

Closing Announcements

Ray Plzak thanked everyone for attending and encouraged all those present to complete the meeting survey available on ARIN's website and reminded everyone that filling out the survey automatically entered them in a raffle. He again expressed thanks to the meeting sponsors: Server Central and ANet. Ray provided reminders about the Registration Services Help Desk and the ARIN Learning Center.

Meeting Adjournment

The meeting was adjourned at 17:36 CDT.