Rehoming a prefix: moving your space to a new origin AS without a gap or a hijack alarm

If you are halfway through it now: read the RPKI row before you touch anything

If part of the internet cannot reach you and both announcements are up, look the prefix up and read the Routing panel before withdrawing either one. The RPKI row prints the validator's answer in RIPEstat's own words, valid, invalid_asn, invalid_length or unknown, and it prints that answer for one origin only, the first origin the report found for the prefix, which during an overlap may be either of yours. Read it with that in mind. invalid_asn means a ROA covers the prefix and names a different network from the one checked: if the new origin has no ROA yet, the networks that validate are dropping its announcement, and the fix is a ROA for the new origin, not withdrawing the old announcement and not revoking the old ROA, because the old announcement under its own ROA is what is keeping you reachable in the networks that validate. invalid_length means the announcement is more specific than the ROA's maximum length allows, the trap in why an RPKI invalid prefix is dropped. Unknown means no ROA covers the space, the not-found state the RPKI post defines as unsigned rather than wrong, which is not a failure and is not protection either. Two cautions before believing any of it: the row is served from a cache and can predate the ROA you made this morning, so read the Sources panel's state for that dataset, and if the routing datasets did not answer there is no Routing panel at all, which is a missing answer rather than a verdict.

The Validating ROAs table beneath the row lists every ROA the validator found for the prefix, one row per ROA with its origin and maximum length, and each row's validity is judged against that same single origin, so during an overlap the other origin's ROA reads invalid_asn even when both ROAs are correct; on unknown there is no table at all. A valid row is therefore not proof that both origins validate. Check each origin and prefix pair yourself at RIPEstat's RPKI validation lookup, which the after transfer checklist shows how to read, and only then decide whether the fault is the ROA or something else, an upstream filter built from the IRR or a route object that does not name the new origin, in which case the old announcement stays up while you find it.

What changes in a rehoming, and what does not

The holder does not change, so the Registration panel does not change: the same Organisation, the same Type string from the registry, no transfer at any registry. That is the whole difference from the after transfer checklist, where the records that die with the old holder are the subject; here nothing dies. The resource certificate stays, and so do the ROAs on it; the transfer case, where both go, is that section's subject. Three things trigger a rehoming, and two of them are already written up from the outside as the false positives a reader is told not to mistake for a hijack. Bringing up your own AS, which choosing an origin weighs and what is an ASN explains who needs, where the policy still differs by region as that post sets out; the one development since is a new RIPE proposal to simplify a prefix holder's first ASN, published on 7 July 2026 and still open in the RIPE policy process. Consolidating several networks into one after an acquisition. And pulling BYOIP space back out of a cloud, or into one, where the cloud's ASN is the origin unless you brought your own AS number to the cloud as well, in which case leaving changes no origin at all.

What you can rehome is your own allocation or provider independent space. A provider's assignment goes back to the provider when you leave, and the right to publish a route object or a ROA for it sits with whoever holds the covering record, which PA versus PI spells out. And what a rehoming does not do: it does not clean the addresses, which the origin post says plainly, and it does not remove the old origin's row from the block's past, which reading routing history shows outliving the announcement itself.

First, the ROA for the new origin, before its first announcement

A ROA names one origin. RFC 9582, the current ROA profile from May 2024, says that a holder who needs to authorise several networks for the same prefixes issues several ROAs, one per AS number, and RIPE's ROA documentation says the same in operational terms, as the two origins post quotes. ARIN's FAQ says each ROA includes exactly one origin AS and that additional ROAs are required for multiple origins; its rule against duplicate and overlapping ROAs is scoped to the same origin AS, so it does not stop the second one. Two ROAs for one prefix is the normal shape of a handover, not a conflict. So the first step is a ROA naming the new AS at your registry's hosted RPKI, with the old origin's ROA left exactly as it is, and the order matters because of how validation works: a route matches a ROA only when the origin AS is equal, so the moment any ROA covers the prefix, an announcement from an unlisted origin is invalid rather than unknown. If the prefix reads unknown today, the old origin has no ROA and the first ROA you publish would make its live announcement invalid, so on an unknown prefix the old origin's ROA is published and read back first, and only then the new one; that first ROA has to cover every prefix and length the old origin actually announces today, read from a looking glass rather than from memory, or the very step meant to avoid an invalid window creates one at the more specific. Announcing from the new AS before its ROA exists, while the old origin's ROA covers the prefix, is the invalid drop in one step.

Two details of the new ROA. Maximum length: RFC 9319, the current best practice from October 2022, says operators should use minimal ROAs covering only what is actually originated, and in general should avoid the maxLength attribute, with two stated exceptions, a ROA under which every more specific the maximum length permits is really announced, and one where the maximum length is substantially longer than the prefix and a large number of the more specifics in that range are announced; RIPE's page adds that when maximum length is not set the AS is authorised for exactly the prefix and nothing more specific. So for a prefix you announce whole, no maximum length at all. Verification: read the new ROA back before step two, at your registry's dashboard and at RIPEstat's RPKI validation lookup for the new origin and the prefix, and expect a wait, which the operators publish in their own terms and this post repeats only as they state them. ARIN's FAQ says its repository is published every five minutes and that users should expect between 30 and 60 minutes after a ROA is generated before it affects routing. RIPE NCC's certification practice statement, RIPE-851 of 13 January 2026, sets an eight hour ceiling for publishing issued material; its help pages give no typical figure. The clouds state their own intake: AWS says it might take up to 24 hours for a ROA to become available to Amazon, and Azure says to allow at least 24 hours for it to become available to Microsoft.

When a cloud is the announcer, the ROA names the cloud's AS, and the cloud's own page governs its shape. AWS documents the commercial region ROA choosing an origin quotes, AS16509 with AS14618, plus AS8987 alone for GovCloud, and AS16509 with AS214101 for its European Sovereign Cloud, alongside the ASNs already authorised; on its EC2 path the maximum length is the size of the CIDR brought in, and on its IPAM path it is fixed at /24 for IPv4 so the block can be split across regions. AWS also tells a customer migrating in to create the ROA for the existing ASN before the Amazon ones, which is the same rule seen from the cloud's side: the origin announcing today is covered before the new one is added. Google documents AS396982 for Premium Tier and AS19527 for Standard Tier, which its page marks as preview, for Standard Tier recommends separate ROAs for the public advertised prefix and each top level public delegated prefix over the alternative it also lists, a single ROA with a maximum length of /24, and for Premium Tier asks for one ROA for the public advertised prefix, and recommends a further ROA for the same prefix naming your own ASN so that the prefix is not invalid if you ever announce it yourself, which is the coexistence rule stated by a cloud; its pages were last updated on 26 August 2026. Azure documents origin AS8075, AS8070 for its US Government cloud, a prefix length that should exactly match the prefixes Microsoft advertises, and a ROA for any existing ASN advertising the range during migration. OVHcloud's BYOIP guide asks for a route object naming its AS or your own and mentions no ROA at all, so the pattern is a cloud's, not a rule. The one registry statement about coexistence over time is APNIC's, in a blog post of 9 August 2022: a two week window after a live transfer for deleting the old ROAs, during which it says the old and new ROAs coexisting will not cause routing problems, which the two origins post already carries.

Second, the paper the new announcer and its neighbours will check

A ROA satisfies the networks that validate. The networks that build filters from the IRR need a route object naming the new origin, in your registry's own database first, and the route objects post gives the order, ROA first then the object, with why an upstream asks and who may create it when the announcer is not the holder. Two tools say in their own words what is checked. IRRexplorer's report calls it a danger when no route object matches the origin seen in the routing table and tells you to create one, expects the object in the database of the registry responsible for the prefix and treats a copy that exists only in another IRR as a warning, and calls a ROA whose origin does not match the announced origin a danger with the ROA as the fix. bgpq4's source list, which the route objects post quotes, means an object registered only where the upstream does not look is an object the upstream's filter never sees. Two developments soften the second half. RADb announced RPKI Auto Objects for 8 July 2026, ROA derived pseudo route objects presented in its feed, and a query to its whois on 7 September 2026 returned one beside the registered object; and ARIN's ROA page says that when enabled, auto managed IRR route objects are created from the contents of ROAs. Neither page says a registered object is no longer needed, so register one.

The upstream's own onboarding is the other half of the paper, and what providers actually check already carries the named providers as read on 19 August 2026: registry agreement with the contract, a letter only on a mismatch, a token, or a signed authorisation. The reason a new upstream will not carry the new origin on your word alone is MANRS Action 1, the compulsory filtering action, which asks a network operator to announce only the AS numbers and prefixes it or its customers are legitimately authorised to, and says it is most important to secure inbound advertisements, especially from customer networks, with explicit prefix level filters or equivalent mechanisms; documenting your own routing intent in an IRR, or with ROAs in lieu, is Action 4, and is your side of the same bargain. Filters rebuild on the upstream's own schedule, which the route objects post quotes for the operators that publish one, so the object goes in before the day you plan to announce, not on it. One cloud specific rule: AWS writes its own RADb object for a BYOIP range, tells the customer to make no manual change for BYOIP in RADb or any other IRR, says a manual change that includes the BYOIP ASN makes the provision operation fail, and says nothing about deleting that object after deprovisioning, so an old AWS origin's object is AWS's to remove.

Leave the old origin's route object in place until the old announcement is gone; a stale object is harmless while the announcement it describes is real. What happens to it afterwards depends on where it lives. Once the old ROA is revoked, an object naming the old origin becomes RPKI invalid, and RADb refuses to create such objects and stops returning existing ones, which the route objects post and the checklist both carry. In RIPE-NONAUTH the conflicting object ages out under the fourteen day rule of RIPE-731 that the route objects post quotes; RIPE-731 says RIPE managed resources are not affected by that procedure, so an object in the authoritative RIPE Database is not deleted for you; and a registry that does no RPKI filtering keeps the object until you delete it. So delete it yourself in every registry where you put one, and leave a provider's own object, such as AWS's RADb object, to the provider. RADb's stale badge will not do it for you: its stale test exempts a pair whose AS objects share a maintainer, which an own AS rehoming usually is.

Third, the overlap: announce from the new origin, verify, then withdraw the old

With the ROA published and the object registered, announce from the new AS while the old announcement is still up. To anyone reading the block from outside this is the two origins shape, and it is worth being honest about how it reads: the site's own docs say multiple origins are normal for anycast and worth attention everywhere else, and hijacked or transferred treats an authorised handover as a withdrawal and a new announcement with at most a brief planned overlap, while an overlap that never ends is the shape that keeps a reader reading. So keep it short, add the new origin to whatever you have watching the block before its first announcement, because a monitor that alerts on any origin but the one you declared will otherwise raise the alarm on your own handover, and have the paper ready before anyone asks: a ROA per origin, a route object for each, and a Registration panel that has not moved, which is the answer to the transfer question before it is put. The two origins post describes the handover overlap as a benign cause with a clock on it; this is that clock from the inside.

What the report shows while both are up. The Routing panel's Origin AS row lists both networks, each with its holder name where the source gives one. The RPKI row judges one of them, as the first section says. The origin history may carry the two concurrent rows the two origins post describes, both marked current. And the Findings panel prints a notice headed The route changed hands., because two networks have now announced the block, and will print It changed hands recently. for the following twelve months; the Time machine marks the day, behind Show all on a busy block, with Origin changed: the old AS to the old AS and the new AS, printed as numbers. None of that is a hijack verdict, all of it is expected, and all of it is what a third party will see, which is why the paper comes first.

Then verify from outside your own network before withdrawing anything: from the collector views the checklist names, from a looking glass, and from a network you know validates, as the RPKI post says; this post gives no figure for how long that takes, because none of the sources publishes one, and the wait is a wait until the reads agree. Two things are not this procedure. Announcing a more specific from the new origin is a different lever with its own ROA and filter consequences, in the two origins post, and on AWS's EC2 path it is not available, since AWS says the exact provisioned range must be advertised, while its IPAM path is the one that splits a block into /24s by region. And when a cloud is at either end, the cloud's documented order governs its end rather than this section. Moving in: AWS recommends stopping the address range's advertisement from other locations before advertising it through AWS and describes a simultaneous stop and start, OVHcloud lists an unannounced range as a prerequisite and says a customer who does not meet it forgoes its assurance of proper functioning and support, Azure allows the old advertisement to run until the Azure side is verified and then asks for it to be disabled, warning that dual advertisement can cause instability or loss, and Google says it does not support overlapping BYOIP route announcements, that importing a prefix advertised outside Google Cloud is not supported and may produce unexpected routing and packet loss, and that for a v1 public advertised prefix for global addresses, which is announced as soon as public delegated prefix provisioning completes, public delegated prefixes should not be created until the prefix is no longer announced from another source. Moving out, the same sentences apply in the other direction: AWS says it cannot reliably support the range or guarantee that traffic enters its network while another location advertises it, Google says it does not support overlapping BYOIP route announcements, and Azure says only that a simultaneous advertisement from elsewhere could cause routing instability or traffic loss, and none of them changes that for the way out, so leaving a cloud is a choice between a gap that lasts as long as the cloud's own withdrawal, which none of the three pages calls short and which Google's page puts at up to 14 days, and an overlap the cloud has said it does not support, lasting as long as the cloud's own withdrawal takes; Azure's regional decommission step is the one published way to shrink the cloud's reach before its withdrawal, and the cloud's withdrawal itself is the step you do not control. What AWS, Google and Azure publish about that withdrawal is the order in the next section.

Fourth, confirming the old origin is really gone

The old announcement stops when the old upstream or cloud actually removes it, and the record catches up when the route collectors stop seeing it. Each cloud publishes its own order and its own figures, quoted here as stated. AWS: release the addresses, withdraw the range with its withdraw command, then deprovision, which it says can take up to a day, and its pages say nothing about the ROA afterwards. Google: delete the delegated prefixes, then the public advertised prefix, and then it says you do not need to remove the ROA naming Google's AS, but if you want to, wait 14 days after deleting the prefix because Google needs that time to stop advertising. Azure: decommission, which it estimates at three to four hours and during which the range is partially advertised, then deprovision, and it strongly recommends decommissioning before modifying or deleting the ROA, because otherwise Microsoft will still be advertising the range without authorisation; it also documents that Microsoft keeps advertising after a ROA's expiry date, and a decommission state that fails with the range still advertised. Between them those pages are the reason the old ROA is the last thing to touch when a cloud is the announcer, and this post applies the same order to any announcer, because a ROA revoked while its announcement is still up makes that announcement invalid wherever validation is enforced.

In the origin history, the old row's When cell reads first seen to current while the collectors still see the old announcement, and turns into a closed range only after they stop; a window that closed recently can still read current for a while, because RIS closes a live window at its last observation and the site allows for that on purpose, and long range views arrive downsampled, which reading routing history and the two origins post both explain. So a still current old row on the day after you asked for the withdrawal is not evidence of bad faith, from the cloud or from anyone; it is a sample that has not caught up, a deprovisioning path that is still running, or an announcement that is genuinely still up, and a looking glass is what separates the third from the first two before the old ROA goes. The row itself is not removed by the site: it stays as long as RIS routing history returns that window, and the site's own persisted observations of it are on the archive endpoint that monitoring your own ranges describes. Only after the old row's When cell has closed and a looking glass agrees the old announcement is gone do you revoke the old ROA and delete the old route object; ARIN says a removal is reflected within 24 hours, and RIPE-851 says a revocation request is processed within eight hours, both as ceilings in their own documents. What to watch during all of this are two of the fields that post tells a holder to diff between runs, the origin set and the RPKI status; a difference on the days of the cutover is the plan working, and the recent change notice will sit on the report for a year and read once, unless the old origin's visibility broke into pieces during the overlap, in which case it counts the pieces.

What the report shows for a rehomed prefix, and what it cannot

The Routing panel: Announced, reading yes or no, and n/a when the panel is drawn but the dataset that answers it did not arrive and no origin was seen; Routed prefix, only when the covering announcement differs from what was typed; Origin AS, every current origin, with a holder name where the source gives one; RPKI, the validator's string for one origin; More specifics, a count of registry objects below the block while the registry hierarchy answered and otherwise RIPEstat's count of related announced prefixes, and Less specific, the one enclosing registry block as a link; a more specific announced by the new origin is read in the origin history, where it has its own row, rather than from that count. Beneath it, the collapsed Validating ROAs table with Prefix, Origin, Max length and Validity, n/a where a value is missing and only valid highlighted. The Origin history panel, one row per origin AS and prefix with covering routes separated below as transit rather than control, is described in reading routing history; what matters here is that the count of separate periods appears beneath a row whose announcement broke into pieces, that a more specific announced by the new origin has its own row in the same table, and that the line No announcement of this exact prefix is recorded. appears only when every row is a covering route; when the routing history dataset has not arrived there is no Origin history panel at all, which the Sources panel will say. The API carries scope and peak peers for each row, which the page does not draw. The Registration panel unchanged through all of it, with the Timeline's Transfers filter empty, is the reader's evidence to a third party that this was a rehoming and not a transfer; that is a reading of the report, not a verdict it prints, and the Last changed row will move if you touch the record for any other reason. The archive endpoint holds the site's own change events and persisted routing observations, as the previous section says. The tags frequent-origin-change and no-rpki exist in the vocabulary for the patterns a careless rehoming resembles; they are applied by a person with evidence, and the absence of a tag is not a finding of innocence.

What it cannot show. It keeps no dated RPKI status per moment: the status and the ROAs are as of the lookup or of the cached answer behind it, whose state the Sources panel shows. A change in the cached RPKI answer between two lookups of the same subject is recorded as a change event on the Timeline and the archive endpoint, dated to the day it was observed, and the Time machine draws none of it, saying in its own words that registration, RPKI and analyst labels are shown only where recorded and never back filled. It cannot give the minute of the cutover; every date it prints is a day, and first seen and last seen come from route collector sampling. It cannot say which of two origins the RPKI row was judged against, so during an overlap it cannot show both validating at once. It cannot show any network's filter state, which is the validator's verdict applied by policy that RFC 6811 leaves to each operator, or reachability from any vantage point. And it does not watch BGP on your behalf: the record grows when someone looks and when cached answers revalidate, and the scheduled lookups in monitoring your own ranges are the watch.