IP Blocks Overview

IP Blocks are a standalone, service-independent resource for Internet IP addressing, managed as persistent resources with their own lifecycle. IP Blocks can move between deployments or services, and can be reused or deleted when no longer needed. IP Blocks are available across all metros and provide a consistent IP management experience. Terminating a service does not automatically terminate the associated IP Block.

You can purchase Equinix-owned IP Blocks or bring your own IP address space for use on Equinix. If you require additional public IP addresses, you can request additional IP Blocks.

Equinix-owned IP Blocks

Equinix-owned IP Blocks are provider-assigned IP addresses allocated to you and billed by Equinix. They are designated for a specific metro and can be used only by services within that metro.

Equinix-owned IP Block sizes:

• IPv4 - /30 to /24
• IPv6 - /64, /48

Equinix-owned IP Blocks are billable according to current pricing.

Customer-owned IP Blocks

Customer-owned IP blocks are provider-independent IP addresses you register with Equinix. Your IP Blocks can be shared by services across different metros.

Customer-owned IP Block sizes:

• IPv4 - /24 and larger
• IPv6 - /48 and larger

Customer-owned IP Blocks are not billed.

To advertise your address space from one or multiple locations, you must have the appropriate route authorizations and Internet Registry records in place and ensure the advertisements are valid in the global routing system. Equinix does not restrict multi‑metro advertisements.

Internet Routing Registry (IRR) Requirements

When using customer-owned IP addresses, a Route Object (RO) must be created in the Internet Routing Registry (IRR) associated with the Regional Internet Registry (RIR), or another IRR such as the Routing Assets Database (RADb). Equinix recommends using a Regional Internet Registry’s IRR.

• Exact‑match route objects must be created for every prefix that will be announced. For example, announcing 198.51.100.0/24 requires a route object for 198.51.100.0/24 exactly.

• Route objects should be created in the IRR associated with the Regional Internet Registry (RIR), such as:

  • ARIN IRR – American Registry for Internet Numbers
  • RIPE Database – RIPE NCC
  • APNIC IRR – Asia-Pacific Network Information Centre (APNIC)
  • LACNIC IRR – Latin America and Caribbean Network Information Centre (LACNIC)
  • AFRINIC IRR – African Network Information Center (AFRINIC)

• You may also announce IP address space obtained from third parties, provided the announcing organization is the legitimate holder or an authorized user of the ASN and/or IP address space. Being a “legitimate holder” and “authorized user” requires a Route Object matching the IP prefix and relevant ASN. Letter of Agency (LOAs) are not an acceptable or valid method to prove legitimacy or authorization.

Using RPKI and Route Origin Authorization

Resource Public Key Infrastructure (RPKI) enables IP prefixes and Origin ASNs to be cryptographically validated by networks worldwide.

Equinix recommends, but does not require, an Route Origin Authorization (ROA) for a prefix advertised to Internet Access at this time. If an ROA does exist the tuple of Prefix/ASN/maxLength must match the Origin ASN and prefix being advertised to Internet Access. An invalid ROA will result in the prefix being dropped. If Equinix is the Origin AS for your prefix and you want to use an ROA, you need to create an ROA that authorizes Equinix to announce the prefix with an origin AS of 15830.

For example:

• Origin ASN: 15830 (Equinix)
• Prefix: The exact prefix to be announced (for example, 198.51.100.0/24)
• Prefix lengths that exactly match the intended announcement (for example, a /24 announcement requires maxLength = 24)

ROAs must be created through the Regional Internet Registry (RIR) where the prefix is registered. Equinix cannot create or manage RPKI ROAs for customer subnets.

Using IP Blocks with Internet Access

Internet Access services that use Static and BGP routing use IP Blocks for your LAN subnets. When you order the service, you select an available IP Block to use. You can also add IP Blocks to an existing service.

• You can advertise both Equinix-owned and Customer-owned IP Blocks simultaneously via BGP when using Internet Access with Fabric or Internet Access with Network Edge.
• Equinix-owned IP Blocks can be shared by BGP Internet Access services within the same metro as the IP Block.
• Internet Access services that use Direct and Static routing cannot share IP Blocks.

When you deprovision your Internet Access service, the IP Block remains in your IP Blocks Inventory for use with another or future service. You can also delete the IP Block separately.

For more information on IP Block usage in Internet Access, see IP Address Allocation.

IP Block Data Visibility

When viewing IP Blocks in the Customer Portal or querying them via API, certain underlying details such as UUIDs and specific IP addresses are abstracted or masked to simplify management and safeguard network security. As a result, the information displayed for an IP Block may not expose all underlying identifiers or address details.

The following visibility rules apply:

• Subnet-level representation — An IP Block is represented as an aggregate subnet in CIDR notation, such as /28 or /24. Individual host IP allocations, internal gateway assignments, and custom customer sub-allocations within the block are not tracked or displayed by Equinix.

• Underlying infrastructure abstraction — Backbone and internal routing identifiers, such as physical interface IDs, internal VRF identifiers, and transport circuit references, are abstracted behind the IP Block and its associated service attachment.

• Provisioning and lifecycle states — While an IP Block or associated Internet Access service is in early provisioning or updating states, certain dependent resource identifiers, such as downstream connection links or peering interface details, may be masked until the resources reach an active, resolvable state.

• Sensitive metadata masking — In compliance-restricted profiles and multi-tenant environments, custom descriptive names, order justifications, and contact identifiers may be sanitized or masked across event logs and inventory summaries.

Summary of Visible and Masked Attributes

Category	Visible in Portal and API	Masked or Abstracted
Addressing	Aggregate prefix in CIDR notation, IP version (IPv4 or IPv6)	Individual host IPs, sub-allocations, internal gateways
Asset Identity	IP Block UUID, metro or location, sourcing type (Equinix-assigned or Customer-assigned)	Internal routing IDs, physical port or chassis mapping
Service Association	Associated Internet Access service UUID, attachment state	In-flight provisioning identifiers, internal orchestration codes
Ordering and Metadata	Lifecycle status, such as ACTIVE, PENDING, or UNASSIGNED	Addressing plan justification notes, audit user credentials

Service-Level Information

Service-level agreement information, including performance characteristics, is documented in the Equinix Internet Access data sheet and the Equinix Internet Access product policy.