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.