Here is my ARIN 43 Policy Preview for the upcoming meeting in Barbados. For those of you who are unable to make the trip down you are welcome to participate remotely. Additional feedback on these draft policies is always welcomed by the advisory council.

There are quite a few policies to discuss at this upcoming meeting, including a number of new wait-list replacement draft policies.

2017-12 POC Notification and Validation Upon Reassignment or Reallocation

Policy Summary: This recommended draft policy requires that a POC be validated upon insertion into the ARIN database.

Discussion:  This policy was presented as a recommended draft at the last meeting in Vancouver, and was sent to last-call and the ARIN board following the meeting. The ARIN board decided to refer this policy back to the AC for additional consideration due to the operational impact that this new policy is expected to have on network operators. The text has been updated to reflect additional feedback and will be presented again to the community for their consideration.

2018-2 Clarification to ISP Initial Allocation and Permit Renumbering

This recommended draft policy attempts to clarify a discrepancy between the IPv4 policy and the IPv4 transfer policy around initial ISP block size, by setting the initial ISP allocation size to a /24.  (The current minimum is a /21).

Discussion:  The ARIN 40 the policy experience report noted a discrepancy in the policy on the initial ISP allocation size depending on if an ISP applied under the old IPv4 Allocation policy (section 4) or if they applied under the new IPv4 Transfer policy (section 8).  This policy attempts to fix this issue by setting the IPv4 policy to match the current methodology used in evaluating transfers.

2018-5 Disallow Third-party Organization Record Creation

This recommended draft policy states that only an authorized representative of an organization can create an organization record in ARIN’s database.

Discussion:  Currently any ARIN member can create an organizational record (org-id) in the ARIN database. This is commonly done when a reallocation or detailed reassignment record is created. This ability, over the years, has allowed ISPs to create multiple records for a single organizations. The goal of this policy change is increase the accuracy of organizational records and decrease the number of duplicative records. This policy like the POC validation policy could be a significant operational change for some network operators.

2018-6 Clarify reassignment requirements in 4.2.3.7.1

This draft policy clarifies which type of reassignment records should be created.

Discussion:  The current policy manual contains some confusing text about when a simple vs. detailed reassignment record should be created. This policy attempts to clarify that a detailed reassignment record is only required when the assignment will be routed outside of the providers network or the customer requests the detailed record.

Wait-list Update Draft Policies

2019-1 Clarify Section 4 IPv4 Request Requirements

2019-2 Waiting List Block Size Restriction

2019-6 Longer Hold Time Requirements for 4.1.8 Recipients

2019-7 Elimination of the Waiting List

Discussion:  In February, the ARIN board suspended the current wait-list policy. In their suspension notification the board noted the reason for suspension as “potential misuse of number resources under NRPM section 4.1.8 (Unmet Requests).” Since the suspension, the AC has been tasked by the board to consider the updates to this policy as allowed by PDP (10.2).

Additionally, a number of members of the community have submitted additional and sometimes overlapping ideas about how number policy should be updated.

This is my summary of the PPML discussion:

• The community generally supports reinstating the wait-list in some form
• The community appears to support /22 as the maximum size, although there were some comments toward going smaller to match APNIC’s /23 and RIPE’s /24 evolving policies
• There is support for allowing the existing organizations on the wait-list to modify their requests to match the new maximum block size
• A segment of the community appears to support restrictions on a per organization basis
• A segment of the community supports some form of fee or block auction to reduce the arbitrage value of the resources; three different avenues were noted to achieve this goal
  • semi-static waiting-list fee
  • blocks are “auctioned” via existing brokers
  • ARIN directly “auctions” blocks
• There was some discussion around restricting the transfer of blocks received by the wait-list including 8.2 & 8.3/8.4 transfers

2019-3 Update 4.10 – IPv6 Deployment Block

This draft policy updates the special purpose IPv4 block to facilitate IPv6 transition. Specifically, this policy sets all blocks as a /24 and cleans up the utilization requirements.

Discussion:  The current transition policy allows for a minimum of a /28 to be issued by ARIN. ARIN, however, does not currently have the technical ability to assign smaller than /24 blocks. Furthermore, a /28 practically is unroutable, so an organization if they were to receive a /28 would be unable to functionally interoperate with most IPv4 end points.

This policy attempts to address these issues, by raising the minimum size to a /24 and limits total amount an organization can receive to a /21. The policy also clarifies the utilization requirements by placing them directly in this section rather than a reference to the utilization requirements of end users.

2019-4 Allow Inter-regional IPv6 Resource Transfers

This draft policy allows IPv6 blocks to be transferred between RIRs.

Discussion:  The current current problem statement notes that the lack of acceptance of the relying party agreement for ARIN’s RPKI trust anchor as one of the reasons to permit an organization to transfer IPv6 resources to another RIR.  This is likely only one of the possible reasons that an organization may which to transfer resources.

Here is my ARIN 42 meeting report for Vancouver, BC.

2017-12 Require New POC Validation Upon Reassignment

Policy Summary: This recommended draft policy requires that a POC be validated upon insertion into the ARIN database.

Discussion:  Under current policy an ISP can insert a Point of Contact (POC) record into the ARIN database without any “acceptance” by the POC.  This has led to situation where incorrect or undesired data is entered into the ARIN database for reassignment or reallocation records.  Often POCs would not know records have been inserted into the database until 1 year later when the POC is validated.  This policy requires that the POC be valid on insertion, and if the POC is not validated, then the insertion of the reassignment record is rejected by ARIN.  This policy was widely supported by the community at the meeting.

2018-1 Allow Inter-regional ASN transfers

Policy Summary: This recommended draft policy would allow ARIN to transfer ASNs to another RIR.

Discussion:  APNIC and RIPE have adopted policy changes that would permit ASNs to be transferred between RIRs.  It is understood that some organizations may wish to move or consolidate their resources in a different RIR and allowing ASN transfers would move toward this goal.  This policy was widely supported by the community at the meeting.

2018-2 Clarification to ISP Initial Allocation and Permit Renumbering

This draft policy attempts to clarify a discrepancy between the IPv4 policy and the IPv4 transfer policy around initial ISP block size, by setting the initial ISP allocation size to a /24.  (The current minimum is a /21).

Discussion:  At ARIN 40 the policy experience report noted a discrepancy in the policy on the initial ISP allocation size depending on if an ISP applied under the old IPv4 Allocation policy (section 4) or if they applied under the new IPv4 Transfer policy (section 8).  This policy attempts to fix this issue by setting the IPv4 policy to match the current methodology used in evaluating transfers.

2018-3 Remove Reallocation Requirements for Residential Market Assignments

This recommended draft policy removes a policy related to the original cable address policy.  Under the current policy cable organizations were required to create reallocation records for each market area to show utilization.

Discussion:  This policy is no longer needed as ARIN’s free pool is empty.  This only removes the requirement to create this records.  ISPs are free to create these records in ARIN’s database if they would like to do so for other reasons.  This change was supported by the community.

2018-4 Clarification on temporary sub assignments

This recommended draft policy clarifies when sub assignment records should be created.

Discussion:  In other regions, specifically RIPE, their policies required reassignments for a wide range of organizations and types of usages.  Some organizations were blocked from receiving additional allocations.  This policy clarifies that transient assignments do not need to be recorded in ARIN’s database. This change was supported by the community.

Next week is the ARIN 41 meeting in Miami, FL.     Here is my look ahead at the policies being discussed at the meeting.  We will have five recommended draft policies and three draft policies to discuss during the 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 recommended 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 online services if records are not updated.  This policy was discussed at the last meeting in San Jose.  This policy seems to have struck the balance between encouraging updates and not removing excess data from the database.

2017-8 Amend the Definition of Community Network

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

Discussion:  The community network policy in the ARIN region has been very rarely used.  This new definition attempts to redefine the policy and update the definition of community network such that additional organizations can qualify for small blocks of resources under the community networks policy.  This policy draft also allows community networks to ISP like services (e.g. the ability to create reassignment records for customers, but does not allow community networks to create reallocation records)

2017-10 Repeal of Immediate Need Policy

Policy Summary: This recommended draft policy removes the Immediate Need policy from the IPv4 section of the policy manual.

Discussion:  The immediate need section has not been used since ARIN’s IPv4 free pool has been exhausted.  Since ARIN cannot provide addresses within 30 days this policy is not longer operative.  By removing this policy section we are simplifying the IPv4 policy.

2017-12 Require New POC Validation Upon Reassignment

Policy Summary: This recommended draft policy requires that a POC be validated upon insertion into the ARIN database.

Discussion:  Under current policy an ISP can insert a Point of Contact (POC) record into the ARIN database without any “acceptance” by the POC.  This has led to situation where incorrect or undesired data is entered into the ARIN database for reassignment or reallocation records.  Often POCs would not know records have been inserted into the database until 1 year later when the POC is validated.  This policy requires that the POC be valid on insertion, and if the POC is not validated, then the insertion of the reassignment record is rejected by ARIN.

2017-13 Remove ARIN review requirements for large IPv4 Reassignments and Reallocations

Policy Summary: This recommended draft policy removes a requirement for ARIN to review large IPv4 reassignment or reallocation records when they are inserted into the ARIN database.

Discussion:  Under current policy ARIN must review and accept a large (/18 or /19 or larger) reassignment and reallocation records.  This requirement was to ensure that all ISP organizations were following RFC2050 requirements for downstream large assignments.  Since the free pool is now empty and it is unlikely ISPs will assign large blocks this policy is extra work by ARIN that is no longer needed.  Removal of this section is also a cleanup item to the ARIN IPv4 numbering policy.

2017-9 Clarification of Initial Block Size for IPv4 ISP transfers

2018-2 Clarification to ISP Initial Allocation and Permit Renumbering

2017-9 Policy Summary: This draft policy attempts to clarify a discrepancy between the IPv4 policy and the IPv4 transfer policy around initial ISP block size, by setting the initial ISP transfer blocks size to a /21.  (The current minimum is a /24).

2018-2 Policy Summary: This draft policy attempts to clarify a discrepancy between the IPv4 policy and the IPv4 transfer policy around initial ISP block size, by setting the initial ISP allocation size to a /24.  (The current minimum is a /21).

Discussion:  At the ARIN 40 the policy experience report noted a discrepancy in the policy on the initial ISP allocation size depending on if an ISP applied under the old IPv4 Allocation policy (section 4) or if they applied under the new IPv4 Transfer policy (section 8).  These two policies take the opposite approach to rectifying this discrepancy.

2018-1 Allow Inter-regional ASN transfers

Policy Summary: This draft policy would allow ARIN to transfer ASNs to another RIR.

Discussion:  APNIC and RIPE have adopted policy changes that would permit ASNs to be transferred between RIRs.  At this time we are not aware of any usage of the current interRIR ASN transfer policy.  It is understood that some organizations may wish to move or consolidate their resources in a different RIR and allowing ASN transfers would move toward this goal.  There appear to be some technical details that still need to be considered on how to record the transfers between the RIRs and how the IANA top-level ASN registry would or would not reflect the reallocation of an ASN to a different RIR.

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