RIPE Address Space in the ARIN Region

You can. Here is why RIPE policy allows it, why ARIN's out-of-region rule is about something else entirely, and how a prefix registered in the RIPE Database ends up announced from a network in Denver.

Audience: network and platform engineers in the United States and Canada evaluating IPv6 address space, and anyone who has been told that address space belongs to the region it came from.

Last updated: September 2026

The short answer

Nothing in RIPE policy restricts where an allocation is used, or requires the End Site to be in Europe. The constraint that does exist is on the member, not the customer: isp6 is a UK company, which is what qualifies us to hold the allocation we assign from.

Routing does not care either. A prefix is a prefix, and no part of BGP or RPKI records which registry issued it.

If you have heard that out-of-region use needs justifying, you are thinking of ARIN's rule, and it is a real rule. It governs ARIN members using ARIN resources. It has nothing to say about RIPE space.

Does it route the same?

Yes, and there is no mechanism by which it could not.

Route acceptance is decided by your transit providers and peers, using prefix length, the origin AS, and RPKI validation state. None of those inputs contains the issuing registry. A route6 object in the RIPE Database and a ROA under RIPE's trust anchor are validated by the same relying-party software that validates ARIN's, and both chain to the same five RIR trust anchors that every validator ships with.

The practical test is simply whether your prefix is registered, has a valid ROA, and is long enough to be accepted. A /48 clears the customary filter everywhere. Anything longer does not, from any registry.

What RIPE policy says

ripe-738, the IPv6 Address Allocation and Assignment Policy, contains no geographic restriction on use. Neither does ripe-637, which sets the contract terms behind provider independent resources. Where an End User sits is not a fact either document asks about.

Both are short and both are linked. Read them if you want to see it for yourself.

The one geographic requirement in the system applies to us, not to you. A RIPE NCC member needs a registered office in the service region, which is why isp6 is a UK company holding a /29 rather than a US one.

ARIN's rule is about ARIN resources

If you have been told that out-of-region use needs justifying, you are thinking of §9 of ARIN's Number Resource Policy Manual, and it is a real rule. It covers ARIN members asking ARIN for more ARIN resources, and when usage outside North America counts towards that case.

It has nothing to say about a prefix in the RIPE Database. ARIN administers its own resources.

This comes up often enough in questions from operators in the United States and Canada that it is worth setting down in one place, which is why this page exists.

The confusion is fair enough. If one registry scrutinises out-of-region use, it is natural to assume they all do. RIPE never wrote an equivalent section, because location is not a fact its policy treats as relevant.

Getting it announced

Holding a prefix and announcing one are different problems, and the second is where a US network usually expects friction: finding a transit provider willing to accept a European prefix from a customer.

The cloud route removes that question, because the hyperscalers announce BYOIP prefixes from their own global ASNs rather than from anything region-specific.

So a /48 brought into us-east-1 is announced by exactly the same autonomous system as one brought into eu-west-2. You authorise it the same way, by adding a ROA for the provider's ASN from the cloud panel on your subnet dashboard, and the provider verifies ownership against the RIPE Database and the RPKI. The AWS BYOIP guide covers the sequence in full, and nothing in it changes by region.

On your own network the requirement is the ordinary one: an ASN and a provider that will accept a /48 with a valid ROA. That conversation is the same on either side of the Atlantic, and the ROA is what settles it.

Signing up from the United States or Canada

Sign-up is the same form everyone else uses. It verifies an email address, then a mobile number by SMS, then your identity against a photo ID. North American numbers are accepted: pick +1 from the dial-code list and enter the number as you would dial it locally. The identity check takes a US or Canadian passport or driving licence.

Prices are in pounds sterling and euros, shown side by side, and you pay in whichever of the two you choose. We do not bill in US dollars. Your card issuer converts at its own rate, which is usually a small margin over the interbank rate and worth checking with them before you compare us with a provider that bills in dollars. The current prices are on the membership page.

What you get

A membership includes a portable /48. A /44 is available where you need more, and a /44 is sixteen /48s, which is usually the right shape when you want one per account, per region, or per business unit.

Whichever you take is registered to you in the RIPE Database, with an inet6num, route6 objects, ROAs for whichever origin ASNs you nominate, and reverse DNS delegated to your own nameservers under ip6.arpa. All of it is self-service from the subnet dashboard, with no justification process to wait on.

If what you need is space registered to your own organisation rather than assigned from ours, PI space and AS Numbers are self-service applications with isp6 as your sponsoring LIR, and no membership is needed for either.

The part that matters most over a long horizon has nothing to do with which registry issued the block. You hold it. Changing cloud provider, changing transit, or moving between regions is a routing change, not a renumber.

This document is provided for informational purposes. Protocol specifications and cloud provider behaviour are subject to change. Consult the linked RFCs and vendor documentation for authoritative, up-to-date information before making architectural decisions.