What SWIP is and when you must register customer assignments
You hand a /24 to a customer, and somebody asks whether you have SWIPed it. The word is ARIN's, the obligation exists in some form at every registry, and the details (which sizes, how fast, what may stay private) differ enough that copying one region's rule into another gets you wrong answers. Here is what a sub-assignment record is, when each registry requires one, what it proves to the person reading it, and why a missing record is not automatically a breach.
What SWIP is
SWIP, the Shared WHOIS Project, is ARIN's name for registering the space you have sub-delegated so that WHOIS and RDAP resolve it to your customer rather than to you. ARIN's policy manual draws the line in section 2.5: a reallocation is space sub-delegated for the recipient to distribute further, a reassignment is space sub-delegated for the recipient's exclusive use, and authorised incidental or transient use by a third party is not a reassignment at all. Three record shapes exist. A simple reassignment carries a customer name entered by you as free text, which ARIN does not vet, and shows your own contacts unless the customer asks for its own point of contact or the block is routed outside your network; a detailed reassignment requires the customer to hold an Org ID under a Registration Services Agreement and gives it its own contacts and reverse DNS delegation, without the right to reassign further; a reallocation requires the same and lets the recipient create records of its own. In WHOIS the NetType tells you who issued the space: Direct Allocation for space ARIN issued (the separate Direct Assignment category was retired on 1 January 2022), Reallocated or Reassigned for space an upstream issued; within Reassigned, a Customer line with a C-handle marks a simple reassignment and an Organization line with an Org ID marks a detailed one. RDAP, and so our report, prints the same shapes as DIRECT ALLOCATION, ALLOCATION and ASSIGNMENT. 64.62.128.0/24 is a simple reassignment registered in 2002 to a customer named in ARIN's WHOIS; 23.94.0.0/25 is a detailed one with the customer's own abuse contact; ARIN's WHOIS lists 173.208.0.0/21 as Reallocated under a /20 that is itself Reallocated.
When ARIN requires it
Under the March 2026 edition of ARIN's Number Resource Policy Manual (version 2025.1, dated 3 March 2026), section 4.2.3.7.1 requires each IPv4 reassignment or reallocation of a /29 or more to be registered via SWIP or a directory service meeting the standards of section 3.2, and 4.2.3.7.2 requires it to be visible within seven calendar days. Every record names the customer, except where policy specifically exempts it. A reassignment carries the customer's own point of contact only if the customer asks or the block is to be routed and announced outside your network, so an internally used reassignment still needs the record, just not necessarily the customer's contacts; a reallocation always needs the customer's organisation name and appropriate contacts, with no internal-use carve-out. Residential customers holding a /29 or larger may appear as "Private Customer" under your name with "Private Residence" as the address, provided your abuse and technical contacts are on the record. Blocks of /30 and smaller need no record, though ARIN may ask for utilisation data. IPv6 has its own floor: static reassignments or reallocations of /47 or more, or any size that will be individually announced. The directory service alternative is RWhois (RFC 2167, port 4321), which ARIN still accepts provided it is available around the clock and current; only SWIP submission by email template was retired, on 3 June 2024. The lever behind all this is plain: ARIN may ask you to justify utilisation at any time, assignment histories included, and says future receipt of allocations may be impacted if you cannot.
The other registries
Outside ARIN the policy documents never use the word SWIP, and the rules diverge. RIPE NCC's IPv4 policy (ripe-826, June 2024) is the simplest to state: all assignments and allocations must be registered in the RIPE Database, only registered ones are considered valid, registration is the final step in making an assignment, and the data must be correct at all times; there is no size floor and no day count. An LIR registers each assignment as ASSIGNED PA, or covers End Users with the same purpose and contact details behind a single AGGREGATED-BY-LIR object, allowed for IPv4 since 1 July 2024, on condition that purpose and contacts are consistent across the whole object and that the LIR can produce assignment statistics in an audit; our own query of the RIPE Database full-text search index on 18 August 2026 returned some 3.9 million ASSIGNED PA objects and under a thousand IPv4 AGGREGATED-BY-LIR ones, an unofficial snapshot, so the old way still dominates. LIR-PARTITIONED PA space is not considered used by policy at all; only the assignments registered inside it count. APNIC's policy (APNIC-127, February 2025) requires registration of delegations larger than a /30, promptly rather than by a day count, lets the provider keep customer details non-public so that WHOIS refers enquiries to it, and makes an Incident Response Team object mandatory on every record. LACNIC's manual (v2.21) requires /29 and larger within seven days, exempts residential customers, and lists geolocation of sub-assignments among its reasons. AFRINIC's consolidated manual requires every assignment to be registered, treats unregistered resources as invalid, and will not delegate reverse DNS for a /24 without one.
What a record proves, and what a missing one does not
A sub-assignment record is the upstream's declaration of an administrative relationship, made at some date; it is not proof of who is using the address today, and it never names the party behind a single event. The customer on the record may be a hosting company with thousands of tenants, an access network putting whole subscriber pools behind one address, or a reseller that carved the block up again and registered nothing. The record tells you which operator to ask; only that operator, matching your timestamp against its own logs, can say whose traffic it was. When the operator being asked is you, the same record read from the other side is what settles whether the reported address is inside space you answer for. A simple reassignment name is unvetted free text, and records can be decades old, so read the timestamps before you read the name. A recent timestamp is not a verification either: it records when somebody last wrote the object, not that anybody checked what it says. A missing customer record, meanwhile, has plenty of innocent explanations: the block is a /30 or smaller at ARIN, the customer is residential and substituted, the provider kept APNIC details non-public, the LIR used AGGREGATED-BY-LIR, the data lives on the provider's RWhois server and only a referral appears, or ARIN's or LACNIC's seven-day window has not closed, a grace period RIPE and AFRINIC do not give you. Two things the record does drive, though, one of them less than people expect. Abuse routing, meaning which mailbox a complaint lands in rather than who is answerable for what happened: in RIPE data the effective abuse contact is the nearest abuse-c walking up from the inetnum to the organisation, so a customer assignment without its own abuse-c inherits yours; at ARIN a simple reassignment shows your abuse contact unless a customer point of contact was attached, and a detailed one shows the customer's. And geolocation, only indirectly: RIPE's own documentation says the country attribute cannot be used in any reliable way to map addresses to countries; the self-published signal is an RFC 8805 geofeed referenced per RFC 9632 from the most specific object, which RIPE holds in a dedicated attribute since December 2021 and ARIN holders currently carry as a Comment line, with an RDAP extension (RFC 9877) that ARIN's RDAP did not yet advertise in August 2026. Vendors weight all this as they see fit and mostly do not say how; MaxMind states it can consume RFC 8805 and 9632 geofeeds. If your customer's block geolocates wrongly, the record and the feed are where the fix starts.
Why it is worth doing well
The registered sub-block is what the world resolves for every address inside it: the name on it, the abuse contact under it, the country hint beside it. Register the customer and complaints reach whichever contacts the record shape carries: yours on a plain simple reassignment, the customer's where a detailed reassignment or a reallocation puts them there, which needs the customer to hold its own Org ID under a Registration Services Agreement; leave the block unregistered and every complaint, every blocklist listing that consults the registry, and every geolocation vendor that reads registry data sees only your allocation and your name. The reverse duty is the one providers forget: when a customer leaves, remove or update the record, because a stale customer name outlives the customer, misdirects reports, and hands the next tenant a block that still answers to somebody else. Treat the registry as a live inventory of who holds what inside your space, and it will save you most of the misdirected reports that a stale one attracts.
Look up any address in your space on the front page to see what the world resolves it to: the most specific registered block containing it, its registry type such as ASSIGNMENT, ALLOCATION or ASSIGNED PA, the organisation and abuse contact as published, and the routing history of the announced prefix covering it with any confirmed tags on that space. If that is your allocation rather than your customer's record, the registry is not serving a customer record beneath it: missing, still inside the seven-day window, held on your own RWhois server rather than at ARIN, or our cached copy predates it; the sources panel on the report says when the registry was last read.