ARIN XV
Public Policy Meeting Minutes, Day 1
April 18, 2005
Call to Order and Announcements
Speaker: Ray Plzak, ARIN President and CEO
Ray Plzak opened the meeting and welcomed those in attendance. He then invited Jim Bound, Steering Committee Chair of the North American IPv6 Task Force (NAv6TF), to address the audience.
Jim also welcomed those in attendance and extended thanks to ARIN on behalf of the NAv6TF and the IPv6 Forum.
Ray began the first day of the ARIN XV Public Policy Meeting at 9:10 AM EDT by introducing those present from the ARIN Board of Trustees, the ARIN Advisory Council, and the Number Resource Organization (NRO) Number Council. He also acknowledged those colleagues from the other Regional Internet Registries (RIRs) in attendance and introduced ARIN's directors.
He continued on with the following announcements:
- 150 total attendees, including approximately 50 first-time attendees.
- ARIN XV registrants attending from 20 U.S. states and the District of Columbia, 3 Canadian provinces, and 9 other countries.
- Awards from the 6th Annual ARIN Foosball Tournament:
- First Place: Darren Kara and Scott Shackelford
- Second Place: Brian Van Lieu and Srinivas Avirneni
- Third Place: Sandy George and Richard Jimmerson
- Bringing Up The Rear Award: Paul Andersen and Marla Azinger
- Thank you, ARIN XV sponsors: Native6 Inc, Smart City, and NTT Communications
- ICANN officially recognized AfriNIC as the fifth RIR on April 8, 2005. Pursuant to a motion passed by the Board of Trustees at its meeting in March 2005, Section 4.8 of the Number Resource Policy Manual (NRPM) is now suspended. This section described special allocations within the African portion of the ARIN region, and with the recognition of AfriNIC as an RIR, is no longer needed.
- ARIN released a new version of its website on April 13, 2005. The new site features revised and expanded content, improved standards compliance, and better navigation.
Ray reviewed the meeting agenda and the printed materials given to each attendee.
At the beginning of the meeting there were approximately 120 people in attendance.
John Curran, as Chairman of the Board, moderated discussions throughout the day.
[ARIN offered the opportunity for remote participation throughout the meeting. Comments from remote participants were read aloud at the meeting and are integrated into these meeting minutes.]
Regional Policy Updates
Speaker: Einar Bohlin, ARIN Policy Analyst
Presentation: PDF PPT
Einar Bohlin presented a summary of policy developments and discussions in the other RIRs' regions. Common policy issues among the regions include:
- IANA policy proposal for allocation of IPv6 address space to the RIRs
- Changes in IPv6 policy within RIR regions
- Privacy of WHOIS data
Einar provided specific details about policy developments and discussions within each RIR region in his presentation.
Policy Proposal 2005-3: Lame Delegations
Presenter: Paul Andersen
Presentation: PDF PPT
Ray Plzak presented an introduction to the proposal. Highlights included:
- Introduced on PPML – March 17, 2005
- Staff Impact Analysis – April 2005
- Moderate implementation impact
- Implementation - within 4-6 months following ratification by the ARIN Board of Trustees while shifting other projects within ARIN
- Legal Review – April 2005
- "…saw nothing that created concerns for liability related to ARIN or issues of compliance with law or regulation."
- Public Policy Mailing List (PPML) Discussion Summary
- There were 26 posts by 10 people. Notable responses included:
- Partially lame - Flag servers or remove them?
- Ultimate goal - Protect global DNS or clean up ARIN database?
- There were 26 posts by 10 people. Notable responses included:
Paul Andersen, as the proposal presenter, continued with the presentation of the proposal. He noted that the proposal's goal was to modify existing policy (Section 7.2 of the NRPM) on lame delegations, based on feedback from ARIN staff. Paul added that when the current policy was originally passed, there was no staff impact analysis.
He explained that this proposal did not deal with whether or not ARIN should actively identify lame DNS servers or reverse delegations, nor was it intended to deal with what procedures ARIN staff uses to determine if an IP address block is lame. It is only intended to clarify what happens after lameness has been determined. He further noted that the current policy has not been fully implemented, and went on to explain what has been implemented and the operational issues that have developed. He concluded by explaining the impact of passing or not passing the proposal.
General Comments:
- I agree the current policy may be a bit more than we wanted, but I am concerned we're going too far in the other direction. To support the proposed text, I would first like to see published the procedures ARIN would implement as a result of being given the flexibility to change these procedures.
- Stepping back and looking at this, I have to wonder if this whole effort is worth it. What exactly are we trying to solve here? If people want to have lame records, that is its own reward in terms of a lot of things not working right. We aren't making sure that they have valid information loaded in the zones, we're just making sure the servers give back an SOA. This isn't making sure there is good data out there. How much farther do we have to go and how much more effort do we expend before we say, 'that was really worth the effort; we've got it all fixed and the Internet is perfect now.'?
- Is this an attempt to clean up DNS or WHOIS? If the goal is cleaning up WHOIS, we shouldn't bother as it would be a waste of time. Cleaning up DNS, on the other hand, would be worth it.
- Notices via postal mail often have the advantage that if it doesn't go to the correct contact at first, it may be forwarded internally.
- If the goal is reclamation, there needs to be some tradeoff between how much effort we put into resolving lame delegations and the size of the block in question. Perhaps if we dealt with the larger blocks first, possibly with more staff, and then moved on to the smaller blocks using less staff, that would be a reasonable compromise.
- We are dealing with folks with lame delegations who haven't noticed and fixed the problem yet. Reasonable due diligence is probably enough, because they're broken now and we're just taking away the brokenness.
Statements For and Against:
- This policy proposal is needed as the policy already on the books is too expensive, and this will make things cheaper.
- I appreciate the fact that it can take a long time to resolve these issues, but this proposal goes too far in the other direction. In addition, I think removing the requirement for sending out postal mail is totally wrong. E-mail is too unreliable due to spam blockers, firewalls, and everything else. At minimum, postal mail should be sent to at least one of the contacts listed. If there is no response to that within 30 days, I can understand then removing the delegation.
- I support the policy proposal as written for similar reasons as those previously mentioned. Any amount of due diligence is enough when we're talking about simply fixing something that doesn't work anyway.
Questions/Responses/Clarifications:
- There appears to be a paramount of discretion on the part of the ARIN staff as to when it will take its particular actions. Is there an attempt to actually speed things up to try and get closure on those 8,000-plus lame delegations and go into maintenance mode, and what is the time frame in which you expect to actually try and do this? Paul Andersen responded that the opposite is actually true. The initial policy came in response to a bug that existed in a particular software vendor's resolver. They fixed the bug, apparently, and that's no longer causing a problem. So the idea is to take it from what was originally implemented and move into more of a maintenance mode. In other words, it's still a problem and it should be cleared up, but not at the same rate that the original policy requested.
- Why does ARIN need additional staff if timeliness is no longer an issue? Richard Jimmerson, ARIN Director of External Relations, responded that the policy, as it exists currently, required ARIN staff to exactly follow four steps, some of which are extremely time- and resource-intensive. If the policy remains the same, ARIN would have to hire more staff to meet the requirements as specified in policy. If the proposal is passed, it would allow ARIN to modify these procedures and have greater flexibility in how these steps are followed.
- Does the contact information mentioned include fax numbers and was it included in the computations of staff time and resources needed? Richard responded that some of these records did include fax numbers, but that current policy didn't mention that as a mode of contact. Faxes would certainly be another method of contact staff could use. Paul Andersen added that this proposal is meant to simply give the staff the flexibility they need to determine what works and what doesn't and implement the proper procedures accordingly.
- If this proposal is implemented, would ARIN publish written criteria on the steps taken to try and resolve these issues? Richard responded that these procedures would be developed by staff and would be published on the ARIN website so that the community could know what ARIN is doing in this regard. There would also be public notification of the procedures.
- What is the actual expected impact on ARIN's budget if the policy is not changed? John Curran replied that ARIN does have enough money to cover the costs for more staff and resources needed to implement the current policy, if so directed by the membership. However, this is a significant amount, and if this proposal were accepted, we could fit the work within the framework of existing staff and resource levels.
- In summarizing discussion from the floor, John Curran asked ARIN staff whether it was viewed that these procedures, if this proposal were implemented, would change once or would be periodically modified. Richard responded that the intent was for the procedures to change only one time.
- Nate Davis, ARIN Director of Operations, offered a clarification as to the intent of the proposal. He stated that the goal was to remove step 3, regarding outbound telephone calls, and step 4, regarding postal mail. ARIN would post the modified procedures and additional educational material related to the issue on its website. In implementation of the current policy, ARIN has found that a majority of those contacted via e-mail did not understand what a lame delegation was from ARIN's perspective.
- Ray Plzak clarified the issue of mailings generated by ARIN's implementation of this section of policy. He noted that steps 3 and 4 would not be completely abandoned, but that the process could be adjusted and remain flexible as we move forward. In addition, while e-mail is not perfectly reliable, neither is postal mail. ARIN could look at having it delivered via certified mail, though that would be an increased clerical burden, but might be appropriate in some cases. That kind of flexibility is not an option under the current policy. Practices will be developed and published, and if there is feedback on those, we will take that into consideration.
- Using the contacts that exist for billing might be a good way to contact people. For the records where ARIN is not getting any response, are these people with space that existed pre-ARIN and so we have no good contact for them, billing or otherwise? Ray responded that most were legacy allocations, so ARIN doesn't send them bills and they don't come back with more requests. Also, there's no guarantee a billing contact that received a notice about this would understand what it is or even who to forward it to. Ginny Listman, ARIN Director of Engineering, added that quite a number of the lame delegations are downstreams and so don't have any direct relationship with ARIN.
- What was the the time period delegations were tested for lameness? Ginny Listman responded that ARIN originally tested everything on one day in the summer of 2003 and came up with 55,000 lame zones. ARIN sent out notices, tested again 30 days later, and came up with 35,000 lame zones. However, last summer, ARIN set up a different program and did the testing for a period of 30 days. At the beginning, there were more zones that showed up lame than at the end of the testing period. Now ARIN only considers it lame if it shows up for the entire 30 day period, which is a change from how ARIN did it before.
End of Discussion:
John Curran took a straw poll of the consensus of those in attendance. There was consensus in the room to move the policy proposal forward.
Policy Proposal 2004-3: Global Addresses for Private Network Interconnectivity
Speaker: Marla Azinger, Proposal Author
Presentation: PDF PPT
Ray Plzak presented an introduction to the proposal. Highlights included:
- Revised text posted to PPML – December 16, 2004
- Presented – ARIN XIII and ARIN XIV
- Staff Impact Analysis – April 2005
- ARIN departments - no significant implementation impact
- Proposed text would not change how IP requests are reviewed by ARIN staff
- Implementation - within 90 days following ratification by the ARIN Board of Trustees
- Legal Review – April 2005
- "…saw nothing that created concerns for liability related to ARIN or issues of compliance with law or regulation."
- Public Policy Mailing List (PPML) Discussion Summary
- There were 23 posts by 13 people. Notable responses included:
- “private address space is a disease that should not be officially encouraged in any way”
- “…encourage people to use IPv6”
- There were 23 posts by 13 people. Notable responses included:
Marla Azinger, as the proposal author, then continued with the presentation of the proposal. She began with an explanation of the current policy text (Section 4.3.5 of the NRPM) and what this proposal is attempting to address. She added that this proposal is merely trying to bring policy and current practices in line with each other, to help people be more informed about the issue. This is simply a clarification in policy of an existing practice.
General Comments:
- There might be value, for people transitioning from 1918 space to globally unique space, in having a phrase referring to utilization, because 1918 space does not have to be efficiently utilized, but globally unique space should, even if it is private. Also, this is going to be address space that is not routed on the Internet, or probably not routed on the Internet, because we're talking about organizations that may not be connected to the Internet or have the intention now to be connected. There's a potential here for address space that is obvious to bad guys to source traffic from, and that is not easily blockable for Autonomous Systems. I don't know how we could address that, and I just wanted to raise that as a potential point.
Statements For and Against:
- Ignoring for a moment the fact that provider independent /48s for IPv6 address space continue to be a nonfinalized subject, "I believe that moving this policy forward without including the phrase "or seriously consider using IPv6 to the extent practicable" is shortsighted.
- I support this policy, but would like some mention of using it efficiently as it may be routed later. I believe this would be a minor change the ARIN AC could address.
Questions/Responses/Clarifications:
- Would it be possible to include some language in the proposed text to state that for allocations under this policy, name servers should not be listed? Marla replied that was a good subject, but was out of scope for the proposal currently being considered.
- Is it currently acceptable for organizations to submit allocation requests without supplying name servers? Leslie Nobile, ARIN Director of Registration Services, responded in the affirmative.
- If I get a public allocation for my private use and it never shows up in the routing system, we just heard earlier APNIC is considering reclaiming that space and pursuing policies around that. There's no specification here as to what happens. Is it available for continued use, or is it subject to reclamation if it never shows up? There's a lot of assumption built into the proposal text, and you need to spell that out and say ARIN will not try to reclaim it just because it's not being routed. I do have to second the comment about seriously considering IPv6. Marla responded that this proposal was only addressing IPv4 policy, and does not address IPv6.
- Paul Wilson, APNIC Director General, added that the APNIC region policy dealing with recovery of address space is explicitly for recovery of unused address space, not for unrouted address space. Holders of address space that is allocated but unrouted are contacted and asked if the space is being used. There is no requirement that they have to hand it back just because it isn't being routed. In addition, last year a policy was passed in the APNIC region for IPv6 allocations to be made to unconnected networks and we are making such allocations at the moment. APNIC's IPv4 policy still requires they be connected because otherwise they can use private address space.
End of Discussion:
John Curran took a straw poll of the consensus of those in attendance. There was consensus in the room to move the policy proposal forward.
Defining Utilization
Speaker: Bill Darte, ARIN AC
Presentation: Due to agenda constraints, this presentation was not given
While this presentation was not made, Ray Plzak announced that one of the intended results of creating the policy manual was that it gives ARIN the opportunity to go back and look at how policies compare to each other and how terms are used.
One of the terms that gets used quite frequently is utilization, both as "efficient utilization," and in other forms. The AC is looking at that and coming up with some definitions. Bill's presentation was intended to report on that work and to alert the community to some things that may happen in the future.
If things can be done as editorial changes, they would be done that way and acted on by the Board. Another case could be that policy changes are required.
Bill Darte added that the work is ongoing, and there will be posts on this topic to the Public Policy Mailing List (PPML) at some time in the relatively near future that will allow for comment on some of the definitions and related topics.
An Alternative Algorithm for the Sparse Allocation Process
Speaker: Mei Wang, Cisco
Presentation: PDF PPT
Mei Wang gave a presentation on the current model of IPv6 allocations and a proposed algorithm that would produce a new model for how IPv6 addresses are allocated.
Highlights:
- Developed an analytical model to quantify the effects of address allocation schemes, looking specifically at performance as it relates to fragmentation and efficiency.
- Routing table growth is one of the key reasons why the method of address allocation is important. How addresses are allocated has a dramatic impact on routing efficiency and routing architecture. For example, fragmentation is one of the key issues in IPv4 right now.
- Multiple factors contribute to fragmentation, but an efficient allocation scheme can alleviate most, if not all, fragmentation resulting from allocation practices. This presentation focuses mainly on aggregation as a method to improve efficiency.
- Propose growth-based allocation scheme, as opposed to current bisection method. This means that the estimated growth rate of an organization is taken into account when allocating space. Growth rate can be in any form. Variations include a fixed initial prefix length, a variable initial prefix length, or the optimization of variable length allocations.
- Using this algorithm, more customers are served without collisions. Another study by Geoff Huston (of APNIC) ran similar simulations assuming linear growth and also showed dramatic improvements compared to the bisection method of allocation.
- Growth-based scheme dramatically reduces fragmentation compared to bisection scheme for any level of address space utilization.
- The growth rate can take any form, including: the percentile of current occupancy, the probability of potential growth, the total projected address space, the probability of extra bits needed, the projected growth rate (in any functional forms of time). Better estimations lead to better results, but what matters most is the relative growth rates among your customers, and there is a natural and dynamic feedback of information as customers come back for more space.
Comments:
- Geoff Huston, APNIC Internet Research Scientist, briefly reported on a presentation he made at APNIC last September on the same subject, but using a different approach in the simulation. It is possible to take the existing statistics files and the delegation of IPv4 addresses and use them as input. What it gives you is the distribution of sizes. You can make some reasonable estimates as to growth rates by figuring out which of the allocations are expansions. In practice, the theory doesn't work that well. The problem is that the allocations are not distributed how you theoretically form them in the simulations. They're more biased towards -- particularly in v6 -- a huge number being one off in the /32 range with extremely long life. The other thing is you double the allocation. So the amount of feedback the system gets about growth rates decreases the larger space you get. If you're growing at the same rate, it's almost doubling now at the time before you come back again. The difference between the normal bisection and rate-managed bisection is not as great as one would like. In my simulations, over some 5,000 allocations, once you get to about a 90 percent fill rate of the block, you're getting about 150 allocations fragmented using normal bisection, and about eight using rate manage. It's not a massive, but a win is a win. More information to automatically manage where you do allocations in a bisected system is a good thing. In looking at the data and simulating on the available data, we don't get as big a win as the simulations would expect.
- Thank you for this presentation. This work is terribly important, and same goes for the work Geoff has been doing here. A lot of this hinges on how good our estimates are of growth. I'm wondering if you want to comment on where we are with that and what the state of knowledge is there. We do have a lot of experience with IPv4, but with IPv6 will the growth rates be different, simply because we're not starting with no Internet and slowly building, but starting off with an existing infrastructure? As people move to v6, quite possibly, they will think, "Well, I've got IPv4. I've already got a huge chunk." The whole pattern of IPv6 allocations may be very different than in IPv4. To get the kind of allocation I hope we get out of v6, I think we'd need to look at very long time lines -- probably many on the order of ten years or longer, which is something we haven't really done for v4 space, because we're under different kinds of pressures.
- John Curran respond that one of the questions that occurs when you ask about the knowledge that we have of growth rates is whether you're asking on a registry-wide basis or on an individual ISP and its own customers. The reality is, for allocations such as this, a process can be applied at the registry level or down at the individual ISP level in dealing with individual customers. Describing the customer level, which I think is what the presentation focuses on, each ISP has its own knowledge of its customers. I don't think ARIN can collect any statistics on typical customer growth.
- Much of the fragmentation that occurs today in IPv4 happens not because of the providers that I think you're trying to address here, but providers with the need to expand. But with these relatively small providers that are getting provider independent spaces, you get a lot of fragmentation. These little companies are getting provider independent space because of the way multi-homing works. On top of that, you get routing table fragmentation with people not getting provider independent space, but announcing their allocations to get multi-homing to work properly. I think we'll find that if, for example, the shim6 proposal by the Multi6 working group gets adopted, then that alone is going to really help the fragmentation problem. I must confess, I'm not enough of a math geek to follow all the math as you went through here, but I understand the conclusion. I think it's a great idea. But I think that to look at fragmentation, there are also issues related to how multi-homing works. As I've said many times, multi-homing is going to fix this problem more than anything else, I think.
- A comment about the shim6 work. Go back to thinking in terms of decades. This is a substantial change to the architecture. By the time we get the process done and get shim6 deployed and up fully, we'll befinding all the things that are broken, and it will take another decade to fix all those. Think in terms of decades here. The granularity and the information you need is spread over the amount of time you're potentially going to run into this conflict collision. It's not going to happen at the same regularity you were used to before. It's going to be much, much slower, just because we have so much more space to work with. These are very big numbers. We have to step back and think in terms of decades.
- I thought the work was really fascinating as well. You looked at the entire address space being bisected from the outset as opposed to bisecting the entire address space initially and working on that. I wonder if there is any utility in just taking half the space. We know that over time there will be consolidation of vendors, new entrants, and that sort of thing.
- Mei Wang replied that this is more of a general model that can be applied at any layer of the allocation. When we have very sparse addresses, it probably doesn't matter to you that much. But when you are getting more and more time on address space, by the time you have very tight address space, you can fit in more customers. Of course, the earlier you start with the scheme, the more space you can save,
- Geoff Huston added that he had done simulations of IPv6 registry using C data as being full. In other words, if the last five years were IPv6 instead of IPv4, what would the allocations look like? Then I did it over a /16, /15, and so on. How big do you start the pool when you do these allocations? The fragmentation outcomes that you get are affected by the pool size. In looking, for example, at a /12 allocation on the RIRs and then running great managed spots, gives you much better outcomes than trying to do it in multiple /16s. It appears what's going on is the relationship of the largest allocations to the total pool size has a dramatic impact on the fragmentation of the block, which is why a /12, actually, made a lot of sense using rate managed allocation to minimize fragmentation outcomes. Whereas a /16 gave you a much higher outcome. The block size is important.
Expanded Address Allocation for Private Internets
Speaker: Tony Hain, Cisco
Presentation: PDF PPT
Tony Hain, of Cisco, provided a presentation on expanded address allocation for private internets.
Highlights:
- There seems to be a conflict in policies. There is an interpretation that networks that intend to be private should use RFC 1918 private space, but that space is sometimes inadequate to meet the needs of larger networks.
- This is compounded by a conflict in attitudes about address allocations. One side feels that good address management is paramount and business process should be modified to fit within space provided and expose operations plans for any public space acquired. The other side feels that business processes and costs are paramount and that allocation policies should be modified to help streamline operations and reject external scrutiny of procedures.
- Propose we add two /8s to the RFC 1918 address pool. Because of a number of factors, best candidates for this are the 1/8 and 223/8 blocks. Only other alternatives are to allow private networks to use public IP addressspace and/or allow businesses to keep sub-allocation information on private networks free from public scrutiny.
Comments:
- I used to be one of these people that needed more than one /8 RFC 1918 because we had a lot of cable modems, and nobody ever wants to give a cable modem a globally routed address. But it seems to me that that would be a really good excuse to finally start using v6 to address things like that.
- Identification concerns with respect to spammers and other naughty people using space they know is not going to be routed is key. While I understand that people can't get public address space and use it internally and not route it, there is, certainly, a problem not having those blocks be readily defined. Even if the space is definitely not going to be routed and it doesn't need to be unique, then it's good not to give unique address space to ten people using one 1/8 or 223/8 or whatever. That's a good idea and I think if you can have two people use the same address space instead of one, that's a win, as far as the organizational stuff is concerned. All that said, if you can use IPv6, that's definitely the thing to do
- Just to really sum it up, this is definitely needed. We've got millions of modems. We're running out of space. We're not having a problem so much as, I'm sure, the Time Warners, the Comcasts, and the Coxes of the world. But having additional space is going to make our lives a whole lot easier. To that point, if we can't use either the 1/8 or the 223/8, what's to say we can't reclaim some of that experimental space in the old class E networks and maybe take one of those to a /8?
- I have worked in organizations that have decided to put 10.0.0.0 with a net mask of 255.0.0.0 on the back ends of clusters of machines and replicate them. It represents a very big problem that people do this. Of course, there's tremendous waste, and you can't use the address space effectively inside the organization. I've seen this happen more than once, and had people share their tales of woe with me trying to undo this. My concern is that by granting one 1/8 and 223/8 equal footing with 10/8, that what we're doing is just increasing the chances for people to do things that amount to bad stewardship inside their organizations. I don't dispute there are groups that could use the extra space. But in the particular case of the cable modems, they get a new address when they reboot anyway. They could very easily transition to other space just by handing out new addresses and waiting a few weeks until everybody's cable modems get new addresses. Although this fixes a problem for a narrow range of people, it doesn't really fix the problem in the wider sense.
- If I were running a cable modem network, it would absolutely be numbered out of public space. They're connected with the Internet. I have no idea why cable modem providers ever numbered them out of private space. I feel sorry for the person who has to combine the Adelphia Network once it's chopped up into two new networks, since that's in the press these days, publicly addressable things that would be divided and combined. Don't see why we won't do it. Plus, on the v6 front, I absolutely think we should be encouraging v6. However, if you want to drive v6 adoption, the best way to do it is to run out of v4 space. If we need to have more private address space and prolong v4 for another 35 years, people will not use IPv6. So please number your cable modems in public space. Assuming we run out, people will start using IPv6.
- I do want to urge you that if you're considering carving out another block for private IP space that maybe you consider reserving it for certain uses. One of the previous proposals, one of the problems was private space. I'd be getting a number of private APM customers. The difficulty is you can't use private space because your customers are already using those blocks. What I'm suggesting is if you're going to put forward another block of private space, reserve a portion of it for non-end-user use for the ISPs only, or people that are aggregating private customers.
- Something that's come up a few times, and I would expect it to come up again is the idea to encourage the adoption of IPv6, we should burn through IPv4 as quickly as possible. And I think that's absolutely irresponsible and completely violates ARIN's principle of stewardship.
- I would be in favor of something like this. We already have organizations out there that we know are currently using 1/8. Why not document it so other organizations can feel safe about using something like that? To say that adding a new /8 to RFC 1918 space is going to keep people from using IPv6, I don't think that's a valid point to keep this off the table. One of the things that's going to have to come up to make IPv6 acceptable for large organizations is there's going to have to be business cases other than just running out of IPv4 space. If there's nothing like that, people will just continue to use other network allocations, like the 1/8, 223/8 or whatever else they want to use, to keep using IPv4 space.
- In the cable industry, there are two areas where address space is used. One is for where they access the public network, and that is done via public address space. But we need private address space for the internal management of those modems. I do have a question about the 1/8 and 223/8 blocks. Why are those deemed unacceptable for public use? I understand one is being used somewhere already. But can somebody tell me about the 223/8 block? That would help me make a decision.
- Tony Hain responded that the last /24 of that particular block had a previous definition. There are some places where that previous definition is still interpreted, and you can't allocate the entire /8 because there's one /24 of it that's not available. But for private address space uses, you could document that fact and probably not impact most people.
- This additional address space that's published as "don't use for routing" is important to a large customer base, such as corporate entities that want to avoid using other people's address space. There's a lot of interconnectivity that, if we did have this, would be a great benefit.
End of Discussion:
Purely as a point of feedback for the presenter, John Curran asked for a show of hands of those in favor of this idea and those against it. With about 100 people in the room, 34 were in favor of the proposal and 30 were against it.
Policy Proposal 2005-2: Directory Services Overhaul
Speaker: Leo Bicknell, Proposal Author
Presentation: PDF PPT
Ray Plzak presented an introduction to the proposal. Highlights included:
- Introduced on PPML – March 9, 2005
- Staff Impact Analysis – April 2005
- Significant implementation impact
- Modification to WHOIS software and databases
- Revise internal procedures
- Revise WHOIS documentation for posting on website
- Add one staff member to the Registration Services Department to maintain/verify APID information
- Implementation - within 12-24 months following ratification by the ARIN Board of Trustees.
- Significant implementation impact
- Legal Review – April 2005
- Steve Ryan, ARIN Counsel, presented the legal review of the proposal.
- I do see the possibility that this policy could generate litigation, but I don't want to say that that's a necessarily negative thing. There are aspects of the policy here that could draw objections from different parties and they might raise them as legal matters.
- With regard to Section 3.4.2, it contains a description of prohibited uses. That policy will, actually, facilitate ARIN's activities, but there is a substantial legal risk of litigation that could result, for example, if we refuse to deal with some person or refer them for review by law enforcement authorities.
- Are there any parts of the current policy with regard to WHOIS that, although we haven't had litigation in substantial quantity so far, presents a substantially different risk from ones we have today? Or do you see ones that could occur in the near future as a result of the current policy and not changing it?
- Steve responded that there are always issues in the current policy that could generate litigation. I do see that the new issues that have been added -- frankly, they're written in very clear language. And that very clear language could raise the risk of additional litigation. But again, sometimes litigation is not a bad thing. Ninety percent of the time it's a bad thing, but there are points at which these policies will be tested. I just wanted to reflect that these policies are the type that may be attacked. For example, a public policy group may attack it and say that ARIN is not being careful enough with information about people's privacy. On the other side, there are business groups and/or law enforcement agencies that depend on some of the information for their own purposes, even though that's not why we collect it, and they may feel they need continued access to it.
- Steve Ryan, ARIN Counsel, presented the legal review of the proposal.
- Public Policy Mailing List (PPML) Discussion Summary
- There were 26 posts by 13 people. Notable responses included:
- Concern about “terms such as SUSPEND, reclaim, offenders, or even non-responsive”
- There were 26 posts by 13 people. Notable responses included:
Leo Bicknell, as the proposal author, then continued with the presentation of the proposal. He started with a history of the proposals relating to WHOIS and how he attempted to combine elements of those proposals into a single proposal for the ease of discussion. He noted that much of the discussion of earlier proposals had focused on how proposed changes interacted with other facets of ARIN directory services, and that this proposal attempts to pull all those ideas together.
He continued on with details of what the proposal addresses, including expected impacts on ARIN staff and the community. He also discussed several amendments that had been proposed on the Public Policy Mailing List (PPML). Among the suggested amendments were some minor wording changes he felt the Advisory Council could address. They included:
- A few people objected to the word "offender" in section 3.2.1, and it could be changed to "resource holder."
- A parenthetical comment could be added next to"reclaim space" as some thought that wasn't clearly defined.
- In section 3.3.1, it probably needs to expressly say that both must agree to the AUP, and that the ARIN staff can publish other data through other methods as long as it applies to the AUP.
- A minor item in that the last three items in 3.3.1.1 were not in listed in order of reference, so they could be resorted.
Some of the key factors of the proposal he noted were that this was a comprehensive look at ARIN's directory services and is based on the idea that published data must be accurate and maintained; sub-allocations may or may not appear; this policy creates a situation where failure to comply with ARIN policies has a recourse beyond not being able to come back and get more space.
Break in discussion:
Due to time considerations, Ray Plzak announced that actual discussion of the proposal would continue first thing the following morning, Tuesday, April 19.
Summaries of this discussion are available in the meeting minutes for day 2 of the ARIN Public Policy Meeting.
Closing Announcements
Speaker: Ray Plzak, ARIN President and CEO
Ray Plzak reminded attendees that the ARIN RSD Help Desk and the Terminal Room were open until 6:00 PM EDT. He encouraged all attendees to complete the meeting survey available on ARIN's website. He reminded the audience about the ARIN social that evening and that day 2 of the ARIN Public Policy Meeting tomorrow would begin at 9:00 AM EDT. Ray concluded by announcing that after lunch, the North American IPv6 Task Force would start its meeting.
Meeting Adjournment
Day 1 of the ARIN Public Policy Meeeting was adjourned at 12:34 PM EDT.