IP Address News

Providing you with a single site about IP Addresses News and Usage

IP Address News - Providing you with a single site about IP Addresses News and Usage

ARIN 40 Public Policy Preview

Next week is the ARIN 40 meeting in San Jose, CA.     Here is my look ahead at the policies being discussed at the meeting.  We will have five draft policies to discuss during the meeting.  This time there are no recommended drafts so no policies will be headed to last-call after this meeting.  If you aren’t going to be there in person check out the remote participation options.

2017-3 Update to NPRM 3.6: Annual Whois POC Validation

Policy Summary: This draft policy make changes to the requirements for managing POC (Point of Contact) records in the ARIN database.

Discussion: This policy is intended increase the accuracy of the WHOIS information by removing records and removing ARIN services if records are not updated.  This policy was discussed at the last meeting in New Orleans.  While this policy so far does not seem to have a lot of support the AC is using this policy draft as a tool to continue the needed discussion around making changes to improve the accuracy of WHOIS records.

2017-4 Remove Reciprocity Requirement for Inter-RIR Transfers

Policy Summary: This draft policy is intended to allow one-way Inter-RIR transfers to the smaller RIRs (AfriNIC & LacNIC).

Discussion: For a while various policies in AfriNIC and LacNIC have proposed one-way policies such that addresses could be transferred into these regions.  There is a feeling amongst those in the LacNIC and AfriNIC communities if they allow 2 way transfers, all their IPv4 addresses will just be lost to other regions with more money.  This policy was intended to allow those smaller RIRs to obtain additional addresses via transfer from the regions which have older legacy space address holdings.

2017-5 Improved IPv6 Registration Requirements

Policy Summary: This draft policy changes the WHOIS reassignment requirements for IPv6.

Discussion: The current policy for IPv6 WHOIS reassignments requires /64 records to be put into the ARIN database.  This does not mirror the current situation with /28’s being required for IPv4.  This policy seeks to make a new threshold of /47 or larger OR any block which will be announced separately.

2017-6 Improve Reciprocity Requirement for Inter-RIR Transfers

Policy Summary: This draft policy is intended to block Inter-RIR transfers to RIRs which do not have reciprocal two-way transfer agreements with their NIRs.

Discussion: Some regions (such as APNIC) have NIRs (National Internet Registries) where organizations within that country go to obtain Internet resources.  It is suggested that some regions do not have reciprocal needs-based transfer policies between the RIR & NIR, and thus one should prohibit transfers to these RIRs since they do not meet the current ARIN requirements of a “RIRs who agree to the transfer and share reciprocal, compatible, needs-based policies.”

2017-8 Amend the Definition of Community Network

Policy Summary: This draft policy changes the definition of a community network in ARIN policy.

Discussion:  The community network policy in the ARIN region has been very rarely used.  Since it has been so rarely used we have discussed if it should just be removed from the policy manual or if it should be updated such that more organizations and networks could qualify.  This new definition attempts to redefine the policy such that additional organizations can qualify for resources under the community networks policy.

ARIN 37 Public Policy Preview

ARIN37Next week is the ARIN 37 meeting in Jamaica.     Here is my look ahead at the policies being discussed at the meeting.  There is one recommended draft that will be discussed along with five other draft policies.  If you aren’t going to be there in person check out the remote participation options.

2015-3 Remove 30 day utilization requirement in end-user IPv4 policy (Recommended Draft)

Policy Summary: This draft policy removes the 30 day usage requirement for IPv4 end-users.

Discussion: This policy is intended to remove what has been considered an onerous requirement on end-users.  Under current policy an end-users is supposed to put 25% of their block into use with 30 days, based upon a 1 year allocation. This requirement has always been very hard for organizations to meet and has skewed the allocation sizes downward.  With end-users now forced to obtain assignments via the transfer market, this policy provision is even more restrictive.

Commentary: There has been some opposition to this policy because a few contributors believe there should be some near-term requirement for organizations which do not have any assignment history with ARIN.  However, I believe most people support removing this requirement.

2015-2 Inter-RIR Transfers to Specified Recipients

Policy Summary: This policy allows an organization which receives a transfer in the ARIN region to transfer it to another RIR within 24 months of receiving the transfer.

Discussion: The policy is intended to benefit large organizations which receive a block via transfer in the ARIN region and then want to transfer it to a subsidiary or other entity in another region.  This is needed for some organizations which wanted to move address blocks to regions/countries which required the addresses be registered in a local NIR before they can be used.  Language was added to the policy requiring the receiving organization be a subsidiary, but despite attempt to finalize the draft language legal issues were raised prevented which the policy from becoming a recommended draft.

2015-7 Simplified requirements for demonstrated need for IPv4 transfers

Policy Summary: Replaces the needs test for transfers with an officer’s attestation to 50% use within 24 months.

Discussion: This policy is intended to loosen the transfer requirements, but leave the other transfer qualification methods intact in case an organization want to use them.  This policy has seen limited support on the mailing list.  The ARIN AC is looking for if there is sufficient support for the ideas within this policy before proceeding to move this policy to recommended.  Issues raised included concern that the 50% utilization level is way to low.  In general, this policy and 2015-9 are supported by organizations which believe in lessening the needs-basis requirements for IPv4 transfers, but not supported by those who believe that the current needs-based requirements are still working and providing value so they should be retained.

Commentary: I personally like the idea of loosening the needs-basis requirements toward officer attestations of use as long as there is a requirement that the address blocks be used on an operational network.  We could quibble about the utilization levels, but 50% per block seems like the lowest one could go and still have the utilization rate be meaningful.  80% has been the requirement for a long time and retaining that level could be beneficial in bridging the gap for those who would otherwise not support the policy.

2015-9 Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers

Policy Summary: Removes needs-based testing from the transfer policy.

Discussion: This policy has been supported and not supported by the “usual” sides in this debate.  This policy was recently proposed for abandonment during the March AC’s meeting, but that motion failed.  Most of the issue revolved around the lack of formal support for this policy.  The AC will be looking for statements of support at the upcoming meeting to see if there is a path forward for this policy.  The text of the policy has not really changed much since the last meeting, other than removing Inter-RIR transfers from the policy as to not upset the interdependent policies between RIRs.

Commentary: I have specifically noted two issues which I believe should be addressed in this policy. 1. I believe there should be a base requirement that address blocks should only be transferred to organizations which intend to use them on an operational network. 2. I don’t like how the policy is constructed from a textual perspective.  The policy uses the phrase “excluding any policies related to needs-based justification”  While I think I know what that means, there is no definitive definition of what exactly constitutes a “needs-basis policy.”  We should be constructing clear text which clearly states any requirements for a transfer.

2016-1 Reserve pool transfer policy

Policy Summary: Restricts the ability to transfer IPv4 blocks which are received from reserved pools including the critical infrastructure pool (4.4) and the IPv6 transition pool (4.10).

Discussion: This is a new policy which grew out of a discussion at the last NANOG meeting in San Diego.  It was noted by some of the participants there that these reserved blocks could be transferred and that was perhaps not what the authors of the reserved block policy had intended.  The current practice allows an organization to obtain a block for a specific purpose and then transfer it to another organization which can use it without restrictions.   The IPv6 transition block was also intended to allow block sizes smaller than /24.  Some contributors believe that if blocks are allowed to be transferred some operators won’t lower their filters to allow these smaller blocks to propagate in BGP.

ARIN 36 Public Policy Preview

arin-36-logoNext week is the ARIN 36 meeting in Montreal.   Here is my look ahead at the some of the policies being discussed at the meetings.  There are two recommended drafts that will be discussed along with nine other draft policies.  If you aren’t going to be there in person check out the remote participation options.

2015-1 IPv6 Initial End-User Assignments (Recommended Draft)

Policy Summary: This recommended draft policy allows organizations which have 13 different sites to qualify for an /40 IPv6 block.

Discussion: This policy is intended to aid the widespread adoption and stabilization of IPv6 by allowing small organizations to obtain a permanent block of IPv6 addresses rather than having to obtain a block from their upstream provider. There has been little opposition to this policy change and I expect it to move forward to Last-Call.

2015-4 Modify 8.2 section to better reflect how ARIN handles reorganizations (Recommended Draft)

Policy Summary: This recommended draft policy clarifies existing staff practice regarding reorganizations.  It explicitly notes that a needs-test is not required for reorganizations.

Discussion: This policy was created by the AC after a Policy Experience Report noted that the current policy is causing some confusion by the membership.  The AC originally consider this as a possible editorial change, but decided that it was best to put this policy through the entire policy process.  There has been no opposition to this codification of existing practice.  I expect this policy to move forward to Last-Call.

2014-14 Remove Needs Test on Small Transfers

2014-14 Policy Summary: This draft policy removes needs testing from blocks which are smaller than /20 and permits an organization to have one needs-free transfer per year as long as a corporate officer attests to the organizations need of the addresses.

Discussion: This policy was rewritten extensively, largely by myself, with input from members of the AC.  When the policy was returned to the list the new text seems to have fallen flat without much discussion.  In my mind this means I have crafted text that now appeals to very few because it makes great compromises between the two sides of the argument for and against needs testing in the transfer market, or people don’t think this type of policy will solve the problems that exist in the current transfer market.  I suspect this policy will likely be abandoned by the AC following the meeting.  Hopefully, at least we have a robust discussion about what types of policy changes are needed as ARIN moves to mostly processing transfers rather than issuing addresses from the IPv4 free pool.

2015-2 Inter-RIR Transfers to Specified Recipients

Policy Summary: This policy allows an organization which receives a transfer in the ARIN region to transfer it to another RIR within 24 months of receiving the transfer.

Discussion: The policy is intended to benefit large organizations which receive a block via transfer in the ARIN region and then want to transfer it to a subsidiary or other entity in another region.  (There is however no restriction in the existing text that it be a subsidiary.)   Some have not supported this policy as it is a “workaround” for broken geolocation issues.  Furthermore some have opposed this as they see potential for increased address market speculation.

2015-3 Remove 30 day utilization requirement in end-user IPv4 policy

Policy Summary: This draft policy remove the 30 day usages requirement for IPv4 end-users.

Discussion: This policy is intended to remove what has been considered an onerous requirement on end-users.  Under current policy an end-users is supposed to put 25% of their block into use with 30 days, based upon a 1 year allocation. This requirement has always been very hard for organizations to meet and has skewed the allocation sizes downward.  With end-users now forced to obtain assignments via the transfer market, this policy provision is much less relevant.

2015-5 Out of region use

2015-6 Transfers and Multi-national Networks

Policy Summary: This two policy drafts are followups to the previous policy 2014-1 Out of Region use.

Discussion: 2015-5 is a rewrite of the original 2014-1 policy but with the an expanded definition of nexus to determine if an organization should be allowed to obtain address blocks from ARIN.  2015-6 is a different look at the same problem and approach it by looking only at the transfer market.  In 2015-6, the policy instructs ARIN to ignore where addresses are utilized when processing transfers.  Currently ARIN only considers a block utilized if a covering route is announced in the ARIN region and the usual utilization requirements have been met.

There has been quite a bit of discussion on these two items and previous policy it will be interesting to see if either or both of them obtain enough support to move them forward to be a recommended policy at a future meeting.

2015-7 Simplified requirements for demonstrated need for IPv4 transfers

Policy Summary: Replaces the needs test for transfers with an officer’s attestation to 50% use within 24 months.

Discussion: This policy is intended to loosen the transfer requirements, but leave the other transfer qualification methods intact in case an organization want to use them.

2015-8 Reassignment records for IPv4 End-Users

Policy Summary: Allows end-user organizations to add reassignment records to the ARIN database.

Discussion: Reassignment records can be used for a number of different functions which could benefit the overall desire to increase database accuracy by allowing organizations to add additional details in the database.  This policy has been weakly supported on the list, but it will be interesting to see if it gathers more support at the meeting.

2015-9 Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers

Policy Summary: Removes needs-based testing from the transfer policy.

Discussion: This policy has been supported and not supported by the “usual” sides in this debate.  It is unclear if anything has changes substantially at this point such that a policy like this could move forward.

2015-10 Minimum IPv6 Assignments

Policy Summary: Sets a utilization “floor” to encourage ISPs to give users an adequate IPv6 allocation per the IETF guidelines.

Discussion: This policy is supported by those who believe that ISPs will not issue large enough blocks (e.g. /56 or larger) to end users.  Statements of non-support have been seen by operators who note that how they provision their network with their users is a organizational decision, not a registry and public policy issue.

2015-11 Remove transfer language which only applied pre-exhaustion of IPv4 pool

Policy Summary: Removes language in the policy manual which was used prior to IPv4 exhaustion.

Discussion: This policy is intended to cleanup the policy manual by removing language that is no longer applicable because the policy conditions under which policy sections were slated to be used are no longer applicable.

ARIN 35 Public Policy Preview

ARIN35Next week is the ARIN 35 meeting in San Francisco.   Here is my look ahead at the some of the nine policies being discussed at the meetings.  There are four recommended draft that will be discussed along with lots of other items on our agenda.  If you aren’t going to be there in person check out the remote participation options.

2014-1 Out of Region Use

Policy Summary: This recommended draft policy allows organizations which have a small block in the region to request resources for use outside of the region.

Discussion: This policy started after it became known that organizations which are generally outside the region were requesting resources and using them almost exclusively outside the region.  The primary motivation for these companies is that IPv4 has already been depleted at other RIRs.  The policy took a number of twists and turns, but in general the community would like to see organizations which are headquartered in the region to be able to get addresses for all of their networks globally.  While this seems simple reducing this to policy has been a challenge.

The policy as currently drafted only requires a small nexus of addresses in the region /22 of IPv4, /44 of IPv6, or 1 ASN.  ARIN’s legal counsel has raised strong concerns regarding this policy and those concerns will likely be the root of the discussion at the meeting.

2014-6 Remove Operational Reverse DNS Text

Policy Summary: This recommended draft policy removes text in the number policy manual which defines ARIN’s operational practice with regard to reverse DNS records.

Discussion: The purpose of this policy is to remove text out of the policy manual which is operational in nature rather than number policy.  It is planned that this operational policy be moved to other locations where it can be updated as needed by ARIN’s operational staff, rather than the number resource community.

2014-14 Remove Needs Test on Small Transfers

2014-14 Policy Summary: This draft policy removes needs testing from blocks which are smaller than /20 and permits an organization to have one needs-free transfer per year as long as a corporate officer attests to the organizations need of the addresses.

Discussion: This policy was rewritten extensively, largely by myself, with input from members of the AC.  When the policy was returned to the list the new text seems to have fallen flat without much discussion.  In my mind this means I have crafted text that now appeals to very few because it makes great compromises between the two sides of the argument for and against needs testing in the transfer market, or people don’t think this type of policy will solve the problems that exist in the current transfer market.  I suspect this policy will likely be abandoned by the AC following the meeting.  Hopefully, at least we have a robust discussion about what types of policy changes are needed as ARIN moves to mostly processing transfers rather than issuing addresses from the IPv4 free pool.

2014-21 Modification to CI pool

Policy Summary: This recommended draft policy sets asside an additional /16 for use by critical infrastructure.

Discussion: The policy is intended to benefit the  Internet exchange point community, which is rapidly changing in the region.  Given the imminent run-out of IPv4 free pool in the ARIN region, this policy is intended to insure that exchange points will have the number resources they need to continue to expand and provide needed interchange services for years to come.

2014-22 Removal of Minimum in Section 4.10

Policy Summary: This recommended draft policy changes the minimum block size from /28 to /24 for the IPv6 transition block.

Discussion: This policy increases the minimum block size because recent testing has noted that smaller blocks may not be routable.  This is, in my opinion, a chicken and egg, problem.  People aren’t accepting smaller blocks because there aren’t many of them now, and they haven’t really been issued by the registries to entities which have the ability to get them routed.  Others believe that the /24 boundary is so engrained in the operator community that they won’t change thus making smaller blocks basically useless to organizations which receive them.  I suspect that the larger ISPs and providers will support this change as it allows them to maintain the status quo rather than changing to support the changing network environment.

2015-1 Change in IPv6 End-User Assignment criteria

Policy Summary: This draft policy changes the assignment rules for small organizations.

Discussion: It was pointed out recently that a type of small organization currently cannot receive an IPv6 assignment because the criteria is too strict.  Furthermore, it is noted that renumbering is a complicated and costly process and these small organizations would not like to have to take on the renumbering process when they change providers.

ARIN 34 & Nanog PPC Preview

arin34_logoNext week is the ARIN meeting in Baltimore.  There also will be a public policy consultation at Nanog 62 on Tuesday morning.  Here is my look ahead at the some of the nine policies being discussed at the meetings.  There is only one recommended draft that will be discussed, but lots of other draft policies are on the agenda and we will be looking for input on how to proceed.

2014-9 Resolve RSA & 8.2 Transfer Conflict

Policy Summary: This recommended draft policy removes two words (“aggregate” and “reclaim”) from the mergers and acquisitions section of the transfer policy.

Discussion: The current registration services agreement, the contract that governs the relationship between ARIN and resource holders, has language which prevents ARIN from reclaiming address space when it is underutilized.  However, the M&A transfer policy has language which prevents an organization from transferring their resource into their new name when they are underutilized.  Because of this, we end up with orphaned records which don’t really match the new organization who is the new resource holder.  Initially the draft policy had language in it which would have solved this problem, but this was removed because a number of critics of the policy believed that needs testing still should be performed and enforced for M&A transfers.

At this point, when IPv4 addresses are assets which can be transferred by sale to another organization, the limits in the M&A policy don’t make sense to me and only seem to create an environment where number resource records are not updated because current utilization rates may not be met across the new or combined organization.  Still this seems like a symbolic change that people have supported and will probably achieve consensus at the meetings.

2014-14 Remove Needs Test on Small Transfers

2014-20 Slow Start Transfer & Simplified Needs

Both of these policies are suggesting changes in the transfer policies due to the imminent run-out of the IPv4 free pool and the changing requirements of the transfer market.

2014-14 Policy Summary: This draft policy removes needs testing from blocks which are smaller than /16 and permits an organization to have one needs-free transfer per year.

2014-20 Policy Summary: This draft is a complex change to both the current IPv4 policy and its related transfer elements.  It seeks to significantly change how we look at the various aspects of obtaining addresses from ARIN or on the transfer market.

Discussion: I believe that changes are necessary for the transfer policy and the existing IPv4 policy as the free-pool is depleted.  How we address these changes is critical to the success of ARIN and its mission, but also the success of the transition to IPv6.  These two policies take different approaches toward the changes which are necessary after IPv4 depletion in the ARIN region.  I suspect there will be a lot of discussion about these two policies and the need to update the existing policy set in a post IPv4 depletion world.

2014-16 Section 4.10 Austerity Policy Update

Policy Summary: This draft policy creates a new subsection of the policy manual to provide an austerity pool of IPv4 resources for organizations which do not currently have any resources directly from ARIN.

I drafted this policy after a number of discussions at the last ARIN meeting in Chicago where it was noted that the current IPv4 policy has limitations inherent in it for new entrants.   This draft was modeled on the successful implementation of similar policies in the APNIC and RIPE regions.

Discussion: Most of the discussion about this draft has been about how to divide up the current /10 and the IANA reclaimed blocks between the existing transition technology pool and the new pool created by this policy.  Hopefully, it will become clear during our discussions if the community supports creating an austerity pool and how they wish to divide up the currently reserved /10 and the IANA reclaimed blocks for new organizations which do not currently have address blocks from ARIN.

2014-17 Change utilization requirements

Policy Summary: This draft policy changes how IPv4 utilization is calculated to deal with limitations on subsequent allocation for some organizations.

Issues:  The draft policy currently changes the utilization definition for all organizations.  The side effect of this is that large organizations could obtain large new blocks just from the implementation of this policy.  A few options to change the draft policy text are being discussed to deal with this issue.

Discussion: This policy fixes a known issue for smaller organizations which has occurred due to the smaller 3-month allocation model that is currently in use for subsequent allocations.  While this policy lowers the utilization bar and has the perceived negative effect noted above for large organizations, this policy as written now could be beneficial for the transfer market as it would make it easier for organizations to meet the utilization requirements for future transfers.

 

NANOG 61 PPC Recommended Draft Policy review

NANOG 61 wrapped up yesterday in Bellevue, Washington.  It is always different attending a conference in your home town; this was also the largest NANOG ever.  On Tuesday morning, ARIN held a public policy consultation.  Since I didn’t get a preview out before the meeting, here is my review of the discussion around the recommended draft policies.

2013-8 Subsequent Allocations for New Multiple Discrete Networks

Policy Summary: This recommended draft policy fixes an issue with the current policy which was highlighted by ARIN staff at an meeting last year.  This policy describes how ARIN should allocate blocks for new sites for organizations which use the multiple discrete networks policy.

Discussion: Previous issues in the policy draft centered around how ARIN should test if/when a site should receive an allocation.  The new text uses the phrase “has shown evidence of deployment.”  There have been no negative comments about this new text and I suspect the AC will move this policy toward last call at their next meeting.

2014-5 Remove 7.2 Lame Delegations

Policy Summary: This recommended draft policy removes section 7.2 which was formerly used when ARIN was conducting DNS lame delegation testing.

Review: This policy has not been in use for some time and the current policy carries some risk to operational DNS should it be implemented as currently written. Furthermore, the operator community has not asked ARIN to reinstate this monitoring service.  I believe consensus has been achieved on this policy and it will move forward to last call.

2014-12 Anti-hijack Policy

Policy Summary: This recommended draft policy adds language to the experimental allocation policy to restrict overlapping assignments.  This policy was created after multiple RIRs allowed an IPv6 research project to proceed by allowing an organization to obtain letters of agency permitting them to use overlapping address blocks.  ARIN has acknowledged that this action was a mistake and will not grant similar permission in the future.

Review:  This policy has been widely supported by the Internet operator community since its introduction.  Some editorial changes were made to the policy just prior to the meeting and the AC must discuss those changes to make sure they do not change the intent of the policy when it was previously moved to its current recommended state.  It seems likely that this policy will also be advanced to last call.

2014-13 Reduce All Minimum Allocation/Assignment Units to /24

Policy Summary: This recommended draft policy changes changes the minimum IPv4 allocation size to a /24 for both ISPs and end users.  This policy was rushed through the policy development process after a few organizations reported that their upstreams would not assign them /24 address blocks and they also could not qualify for an address block under current IPv4 policies.  This policy also fixes issues that ARIN staff highlighted with the shortly upcoming exhaustion of ARIN’s IPv4 free pool.

Review:  While the textual changes of this policy ended up being more complicated that many hoped, I believe the issue which triggered this policy draft will be resolved by this policy and that the additional simplification will also be beneficial.  The staff review raised an issue about the maximum initial allocation size for new entrants.  Current ARIN practice relies on a set of examples which are being removed by this update.  Some discussion was considered about adding an initial maximum, but no agreement could be made on those changes.  In the end, I suspect ARIN will continue with their current practice for block sizing, but an actual maximum would not be enumerated in policy.  I believe this policy will be advanced to last call by the advisory council shortly.

ARIN 33 Recommended Draft Policy preview

ARIN33_logoThe 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.

2013-7 NRPM 4 (IPv4) Policy Cleanup

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.

2014-4 Remove 4.2.5 Web Hosting Policy

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.

2014-7 Section 4.4 Micro Allocation Conservation Update

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.

2014-10 Remove Sections 4.6 and 4.7

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.

ARIN 32 Draft Policy preview and predictions

arin32logoThe joint ARIN 32 & Nanog 59 meeting is coming up next week.  There are a number of substantive public policy items 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.  In this blog entry, I’ve also attempted to make some predictions on the discussion and outcome…

2013-4 RIR Principles

Policy Summary: This draft policy adds a section to the NRPM which would provide guiding direction for ARIN’s registry functions.  The core of these principles were originally found in RFC 2050, but the new draft 2050bis which was recently published as RFC 7020 removed a majority of these guiding principles.

Issues: The majority of the discussion about this policy has centered on two aspects.  1) Should this type of text be inserted at all into the NRPM or is already overlapping with ARIN’s mission statement and text in the Policy Development Process (PDP)?  2) Does the draft policy accurately reflect today’s guiding principles for the RIRs (specifically ARIN) registry functions?  Important issues that have been raised here center around the issue of “stewardship” & “conservation” and how that aspect should be documented in a IPv4 runout RIR.

Prediction: This policy will reach consensus at this meeting and will be sent to last-call for approval.  I suspect there will perhaps be some minor adjustments to the text to accommodate any issues raised during the policy discussion.

2013-6 Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors

Policy Summary:   This draft policy inserts text into the NRPM which would restrict future IP allocations and assignments to organizations who have a legal presences and substantially operate their network(s) inside the ARIN service region.

Issues: This policy originated from ARIN staff comment at the ARIN 31 meeting.  ARIN staff reported that they were seeing increasing numbers of requests from organizations where the IP address were likely to be used outside the ARIN service region or be assigned to customers outside the ARIN service region.  Staff comments on this draft policy indicate this proposed text would restrict the disbursement of resources to legal entities operating within the ARIN service region.

The key issue in this draft policy is the statement:

a plurality of new resources requested from ARIN must be justified by technical infrastructure or customers located within the ARIN service region

Staff comments reveal that this policy as currently written would “create a scenario where a network can’t get IPv4/IPv6 addresses from any RIR.”  Legal review also made note of this issue with this comment: “points of policy to avoid … adopting an overly prescriptive guidance or standard that fails to permit multinational business entities to obtain number resources.”  This is certainly not a desired outcome of the draft policy and I believe must be rectified.

While I believe ARIN staff would benefit from the additional clarity in this draft policy, I doubt this issue will be of as substantial importance after IPv4 exhaustion occurs in the ARIN region.

Prediction: I believe this policy will not achieve consensus at this meeting.  I think there will be significant dissent from the meeting participants to move forward with the current text.  I suspect if the “plurality” statement was removed from the policy it would likely achieve consensus or near consensus such that the policy would continue to move forward through the PDP.

2013-7 Merge IPv4 ISP and End-User Requirements

Policy Summary:   This draft policy makes numerous changes to the existing IPv4 policy which attempts to merge the differences between the ISP and End-User allocation & assignment policies.

Issues: The changes made in this draft policy are complex and intertwined.  It is easiest to see the proposed changes in this red-line version.

https://www.arin.net/policy/proposals/ARIN-prop-190%20proposed_text_changes.pdf

While I believe the general plan to attempt cleanup and streamlining of the IPv4 policy are headed in the right direction, I suspect the changes will not necessarily be well understood by the ARIN community and some skepticism will come about that the changes don’t necessarily all move in the right direction.  In general, this policy seems to loosen the requirements on organizations receiving IPv4 addresses, however these two changes are substantially different.

The utilization requirements on an initial end-user assignment changes from 25% immediate, 50% within one year to 80% within three months. This is offset by the lowering of the minimum block size requirement for single-homed networks.

This change seems to go against the idea of making it easier for initial end-user assignments, but this text changes the initial host count for single subnet from 1024 hosts immediately (25% of a /20) to 819 hosts in 3 months (80% of /22).

The timeframe for additional ISP allocations is changed from three months back to one year.

This change has been suggested a number of times, including 2012-4, since the 2009-8 policy put this into place.  In each instance, consensus generally has been toward not to keep changing the IPv4 requirements as IPv4 exhaustion occurs.

Prediction: I believe this policy will not achieve consensus at this meeting due to the large number of changes being proposed.  I suspect the draft policy will continue to be worked on by the AC and that the text will be updated subsequently and be presented at the next Public Policy Consultation (PPC).

 

ARIN 31 Draft Policy preview and predictions

ARIN 31The spring ARIN 31 meeting is fast approaching.    The final meeting agenda has recently been published. There are also opportunities to participate remotely for those who are unable to make the meeting in person.

Here is my short commentary on the policy proposals being discussed at the meeting.  In this blog entry, I’ve also attempted to make some predictions on the discussion and outcome…

2012-2 IPv6 subsequent allocations

Policy Summary: Changes the way utilization is determined for ISPs who return to ARIN for additional IPv6 allocations.

Issues: Since the initial IPv6 policy was implemented, it has been  understood that the IPv6 policy would need to be modified as implementation experience was gained.  Since the idea of hierarchy is important in IPv6 networks, this policy allows a network’s regions which grow at different speeds to retain the hierarchy structure and still allow fast growing regions to obtain the needed additional IPv6 address space.  Since the draft policy’s introduction there was strong consensus that the existing policy needed to change, the challenge has always been the details of policy text.

Prediction: This policy will finally reach consensus at this meeting and will be sent to last-call for approval.

2013-1 Inter-RIR transfers of ASNs

Policy Summary: Allows organizations to request to transfer an autonomous system number (ASN) from one RIR to another.

Issues: ARIN recently adopted policies which both allow the directed transfer of IPv4 between regions and also allowed the directed transfer of ASNs within the ARIN region. This policy extends this trend to allow ASNs to transfer between RIRs.  Some stakeholders in general disagree with the idea of allowing IP resources to trade and will likely oppose this policy.  On the other side are those who will argue that this policy is a logical extension of the existing policy to allow resources to be transferred to where they are needed.

Prediction: This policy will have signification discussion about the need for the policy and the role of inter-RIR relationships, but I suspect the final consensus at the meeting will be to proceed with the implementation of this draft policy.

2013-2 3GPP IP Resource Policy

Policy Summary: Allows organizations to use a lower utilization requirement for provisioning their 3GPP networks when requesting additional IP addresses.

Issues: Wireless operators have been using space beyond RFC 1918 (such as 1.0.0.0/8) to solve their addressing needs and now that this is becoming part of the “Internet” they need to move off of that space. With ARIN’s /8 inventory currently at approximately 2.5, I’m skeptical that any policy using global IPv4 unicast space can actually solve this problem.   The policy text of this draft policy is also not complete at this time and if consensus is achieved on the concepts of the policy change this draft policy would have to return for discussion at another ARIN meeting.

Prediction: This policy will be abandoned by the AC following the meeting.

2013-3 Tiny IPv6 Allocations for ISPs

Policy Summary: Allows ISPs to request smaller than normal IPv6 address blocks or return larger IPv6 blocks to reduce their IPv6 holdings.

Issues: This draft policy addresses an issue where ISPs are being moved into a larger ARIN fee category under the new fee schedule and allows them to return address space to move to a smaller IPv6 fee category.  There has been significant discussion on the PPML mailing list about this issue and at this point it seems unclear if this proposal will achieve consensus at the meeting.   The primary argument against this policy is that this policy undermines the best current practices for IPv6 subnetting, the intended hierarchical addressing structure defined by the IETF in the IPv6 RFCs, and generous nature of intended IPv6 assignments to end-users.  Some stakeholders will argue that ARIN’s fees shouldn’t be used as a force to dictate a network’s IPv6 architecture.   Arguments for the policy are that some small ISPs don’t need and never will use the current minimum block size of a /32 or /36 and should be able to get a /48 which meets their network needs.

Prediction: This policy will be sent to last call by the AC following the meeting.  (I suspect it is possible that the /48 option will be removed from the draft policy as part of the discussion)

 

ARIN XXIX meeting update

ARIN’s XXIX regional meeting in Vancouver, Canada concluded last week.  A couple of notable discussions occurred.

An updated IPv4 transfer policy 2012-1 was discussed alongside the 2011-1 inter-RIR transfer policy which is pending implementation and board adoption.  ARIN staff noted that the inter-RIR transfer policy will be ready for implementation in about 90 days.  I expect that the ARIN board will implement and move forward with implementing inter-RIR transfers using the revised 2012-1 text which is currently in last call on the public policy mailing list.

A policy 2012-3 to allow ASN numbers to be transferred in a method similar to the existing IPv4 transfers was recommended for last call.  While the circumstances for transfer are different compared with IPv4 transfers, ARIN’s general counsel is recommending that adopting the policy reduces legal liability for ARIN.  During the meeting it was also noted that there is an existing bankruptcy case pending which contains an ASN which has been requested to be transferred.  It seems likely that the board will adopt this policy in due time.

Finally, the community considered a policy 2012-4 to reverse the current 3 month supply restriction on IPv4 allocations.  This policy would have modified the policy to allow a 12-month supply while ARIN has at least a /8 equivalent in its free pool.  This policy would likely have caused the run-out in the ARIN region to proceed faster.  The policy was recently abandoned by the Advisory Council which indicates the current 3 month supply policy is likely to continue until ARIN’s IPv4 free pool is exhausted.