The ARIN 33 public policy meeting is coming up next week in Chicago. There are a number of substantive IP number resource public policy discussions on the scheduled agenda. If you are unable to come to the meeting please consider the remote participation option to have your opinion heard.
Here is my short commentary on the policy proposals being discussed at the meeting. I’ve limited this blog post to the recommended drafts which could go to last call after the meeting since there are so many polices up for discussion at this meeting.
Policy Summary: This recommended draft policy cleans up a number of sections in the IPv4 policy which are no longer relevant due to policy environment changes. For example references to RFC 2050 have been removed since that document has been moved to historical status. The easiest way to look at the changes for this complex change is look at a redline copy of the changes.
Issues: I believe that the controversial elements of the policy have been stripped out from previous versions and all the changes are almost clerical in nature. I expect there to be some discussion about this policy but for it to be supported widely.
Policy Summary: This recommended draft policy removed section 4.2.5 which instructed ARIN to collect technical details about how organizations were using IPv4 addresses for web hosting. It also instructed ARIN to analyze this data for future policy changes. This policy is an artifact of a failed policy attempt many years ago to limit web hosting organizations from using an IPv4 address per host. The data collection appears to not have really occurred and no data was ever analyzed by ARIN.
Issues: This policy section (4.2.5) was a stop-gap policy to completely removing the original failed web hosting policy. It was thought at the time if data could be analyzed then a future policy could be crafted from this data. Operational web hosting has changed in the decade since this policy was put in place and today this policy doesn’t appear to provide any value, especially after the IPv4 free pool has been exhausted. I expect there to be little discussion about this policy and for it to move forward to last call.
Policy Summary: This recommended draft policy changes one word (“two” to “three”) in section 4.4 which defines the number of members which must be present at an Internet exchange point (IXP) for it qualify for a micro allocation. This policy is designed to prevent waste from occurring within the IXP micro allocations reserve block.
Issues: Standard operating practice considers two parties exchanging routes to be a private peering. Since in a two party peering one of the two members could provide an IPv4 /30 block for the peering it doesn’t seem unreasonable to raise the limit from two to three to preserve the long term IXP micro allocation reserve block. Some have argued that this policy will have little effect and amounts to another rearranging of the “deck chairs.” Others have argued that that Caribbean economies benefit from the current policy. The AC was quite split on moving this policy to recommended status and I expect there to be quite a bit of discussion about this single word change in the policy meeting.
Policy Summary: This recommended draft policy changes removes sections 4.6 and 4.7. These two sections provided an aggregation & amnesty program for IPv4 addresses. These sections were suspended in early 2014 by the ARIN board of trustees due to concerns that these sections could be abused by an organization to quickly drain the remaining IPv4 free pool.
Issues: These two sections of the IPv4 policy were rarely used and have not been used in the past six years by any organization. The developing IPv4 transfer market also makes these two policy sections less likely to be used. While there have been some concerns about the removal of these sections, there does not appear to be any substantive use cases which would provide a greater public benefit than the risk of leaving the existing polices in place. Furthermore, if the community desired a smaller amnesty or aggregation policy those could be proposed through the policy development process. No such policy has been submitted by the community so far.