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.