Summary

  • LAC-2026-4 version 1, published on 15 September and still under discussion, would permit inter-RIR IPv4 transfers only between RIRs that share reciprocal and compatible policies based on justified need. That compact sentence contains separate tests for reciprocity, compatibility, need, the rule that triggers validation and the authority that performs it.
  • Current LACNIC and RIPE documents show why the distinctions matter. LACNIC validates need for recipients in its own region; a destination RIR analyzes an outbound recipient. RIPE applies a five-year, 50% use-plan test to an inbound recipient when the source region requires a needs-based receiving policy. The trigger and the validator are not necessarily the same institution.

A policy sentence can look like a checkbox while functioning as a map.

LAC-2026-4 would add one line to section 2.3.2.18 of LACNIC’s Policy Manual: inter-RIR transfers under the section would be allowed only between RIRs that share reciprocal and compatible policies based on justified need. The proposal list records the text as version 1, published on 15 September 2026 and still under discussion. It is not an adopted corridor rule.

The grammar compresses at least five decisions. “Reciprocal” asks whether both registries permit the relevant direction and resource class. “Compatible” asks which clauses can operate together. “Based on justified need” asks what recipient test is sufficient. A separate question identifies which policy activates that test. Another identifies the registry or authority that reviews the evidence and returns a result. A single green compatibility flag would conceal those choices.

The proposal’s rationale says the change is intended to guarantee justified-need analysis for the recipient. It says LACNIC already performs that analysis for intra-RIR transfers and for inter-RIR transfers whose recipient is in the LACNIC region. Its additional note describes the RIPE case more precisely: the requirement applies when requested from the RIR of the source entity. That is the proposal author’s characterization, but current RIPE documents show the same directional mechanism.

The current LACNIC Policy Manual v2.21 already allocates work by direction. A recipient inside the LACNIC region must justify its IPv4 need before LACNIC. A recipient in another region is subject to the criteria, checks and requirements of the corresponding RIR. LACNIC or that other RIR verifies title and the absence of a dispute depending on direction, while the two registries agree the supporting documentation for an inter-RIR operation.

LACNIC’s operational transfer page turns those rules into a hand-off. For an outbound transfer, the offering organization starts with LACNIC. LACNIC verifies and pre-approves, then the destination RIR analyzes the recipient. For an inbound transfer, the origin RIR sends the request to LACNIC, and a LACNIC analyst asks the local recipient for documentation that justifies how the addresses will be used. Completion is coordinated, but the checks are not interchangeable.

RIPE-807 adds the crucial conditional. When resources enter the RIPE NCC service region from an RIR service region whose policies require the receiving region to have a needs-based policy, the recipient must provide the RIPE NCC with a plan to use at least 50% of the transferred resources within five years. For resources leaving the RIPE region, the RIPE NCC follows its own policies and commitments imposed by the receiving RIR.

The RIPE NCC’s inter-RIR procedure makes the sequence explicit. The transferring party starts with the RIR where the resources are registered. The two registries coordinate. If the source region requires needs-based treatment for the receiver, the RIPE NCC evaluates the five-year use plan. A rule at the source side can therefore trigger an evaluation performed at the destination side.

That distinction is the policy-map problem. A corridor may be open in both directions but apply different evidence in each. Two texts may be compatible for IPv4 permanent transfers but not for another resource class. A later policy revision can change one side without changing the other. And a failed transfer may mean that the policies were incompatible, that the need evidence failed, or that the request was routed under the wrong version. “Not approved” does not identify which state occurred.

The public evidence does not yet provide a proposal-specific definition of reciprocal or compatible, a canonical list of qualifying counterpart corridors, or a schema for exchanging validation outcomes. Those are open implementation questions, not defects that can be filled with inference.

Sources