Quick navigation: jump to the pre-deployment checklist

Obtaining a block of IPv4 addresses is only the procurement step. Before the prefix can support production traffic, a network team must establish who is authorized to announce it, how the route will be originated, and how that authorization will be validated by other networks.

This is especially important when an organization uses IPv4 space that it did not permanently acquire. Teams considering leased capacity should understand the full operational workflow described in a guide to lease IP addresses before scheduling a production migration.

Step 1: confirm the intended origin ASN

Start by identifying the Autonomous System that will originate the prefix. That may be the customer’s own ASN, a hosting provider’s ASN, or another agreed network. The choice affects BGP policy, LOA requirements, route objects, and RPKI configuration.

Document the exact prefix and intended origin ASN before requesting any authorization. Small transcription errors at this stage can create a route that looks unauthorized later.

Step 2: understand the LOA requirement

A Letter of Authorization is commonly used as operational evidence that the holder or authorized party permits a network to announce a prefix. Transit providers and hosting networks may ask for an LOA before accepting a BGP announcement.

The LOA should clearly identify the prefix, authorized ASN, relevant organizations, and scope of permission. It should also be clear who can issue an updated LOA if the origin ASN or transit relationship changes.

Internal-link opportunity: Link BGP route announcement to the publisher’s own BGP fundamentals, peering, or transit-provider guide.

Step 3: create the correct ROA

RPKI adds cryptographic validation to route-origin authorization. RIPE NCC’s RPKI documentation describes RPKI as a framework that helps operators make more informed and secure routing decisions.

A Route Origin Authorisation associates a prefix with an authorized origin AS. If the ROA is missing or incorrect, networks that perform Route Origin Validation may classify the announcement differently from what the operator intended.

Step 4: be careful with maximum length

A ROA can specify the most-specific prefix length the ASN is permitted to announce. This is a security-sensitive field. Setting it more broadly than necessary increases the range of more-specific announcements that can validate; setting it too narrowly can make legitimate announcements invalid.

RIPE NCC’s BGP Origin Validation guide explains that an announcement can be valid, invalid, or unknown depending on whether a covering ROA authorizes the origin and prefix length.

Step 5: validate from outside your own network

A configuration can look correct locally while still being wrong from the rest of the Internet. Before moving customer traffic, verify that the route is visible from multiple external perspectives and that the expected RPKI state has propagated.

Check the prefix is visible in global BGP data.
Confirm the observed origin ASN matches the intended design.
Verify the RPKI state from independent validators.
Confirm upstream filters accept the route.
Test reachability from multiple networks and regions.

Step 6: plan change control

Third-party IPv4 space should have a documented process for routing changes. The team should know who to contact for a new LOA, who controls the ROA, what information is required, and how urgent changes are handled.

This becomes important during migrations. A change of transit provider, ASN, or route architecture can require coordinated updates across BGP filters, ROAs, route objects, and operational documentation.

Step 7: include the end of the lease in the design

Route authorization should not be considered only at deployment. When the right to use the prefix ends, the route must be withdrawn and authorization should be cleaned up in the correct sequence. Leaving stale routing objects or ROAs creates unnecessary ambiguity.

Pre-deployment checklist

Prefix and intended origin ASN documented.
LOA issued and accepted by the relevant upstream.
ROA created for the correct prefix and ASN.
Maximum length reviewed and intentionally configured.
Route filters and IRR requirements confirmed where applicable.
External BGP visibility verified.
RPKI validation state checked from independent sources.
Change-control contacts and escalation path documented.
End-of-term withdrawal and cleanup process agreed.

The objective is simple: make the routing authorization as deliberate as the commercial agreement. When BGP, LOA, and RPKI are treated as one deployment workflow, teams reduce the risk of discovering authorization problems after customer traffic has already moved.

For more detail on authorization paperwork, see the role of the LOA in IPv4 leasing.