Understanding inetnum vs NetRange in Regional IP Registrations
A side-by-side technical specification mapping RPSL inetnum objects in RIPE and APNIC against ARIN NetRange structures, clarifying regional registration terminologies.
Quick Answer
inetnum and NetRange are regional database objects defining IP subnet boundaries. 'inetnum' is the standardized Routing Policy Specification Language (RPSL, RFC 2622) object used by RIPE NCC, APNIC, LACNIC, and AFRINIC. 'NetRange' is ARIN's proprietary North American syntax. While syntactically distinct, both map to the same IP boundary concepts in modern RDAP JSON.
- RPSL Standard: inetnum is shared across 4 of the 5 global RIRs.
- ARIN Schema: NetRange uses NetType (Direct Allocation, Reassigned) instead of RPSL status codes.
- RDAP Normalization: RFC 7483 bridges both worlds with standardized startAddress/endAddress objects.
1. Field-by-Field Structural Comparison
Engineers building global IP intelligence pipelines must parse both schemas. Below is the direct semantic mapping:
| Semantic Concept | RPSL Attribute (RIPE/APNIC) | ARIN Attribute | RDAP JSON Path (RFC 7483) |
|---|---|---|---|
| Address Range | inetnum: 198.51.100.0 - 198.51.100.255 | NetRange: 198.51.100.0 - 198.51.100.255 | startAddress, endAddress |
| Subnet Name | netname: CLOUDFLARE-NET | NetName: CLOUDFLARE-NET | name |
| CIDR Prefix | route: 198.51.100.0/24 (in route obj) | CIDR: 198.51.100.0/24 | cidr0_cidrs |
| Delegation Type | status: ALLOCATED PA | NetType: Direct Allocation | type |
| Organization | org: ORG-CF1-RIPE | OrgName: Cloudflare, Inc. (OrgId) | entities[].vcardArray (fn) |
| Technical Contact | tech-c: TCF-RIPE | OrgTechHandle: TCF-ARIN | entities[role="technical"] |
| Abuse Contact | abuse-c: AR123-RIPE | OrgAbuseHandle: ABUSE-ARIN | entities[role="abuse"] |
| Parent Network | parent: inetnum (hierarchical) | Parent: NET-198-0-0-0-0 | parentHandle |
Registry Schema Classification Decision Tree
[ Incoming Regional Registry IP Object ]
|
+-------------+-------------+
| |
[ Has "inetnum" ] [ Has "NetRange" ]
RPSL-Based RIRs ARIN (North America)
RIPE, APNIC, LACNIC, AFRINIC |
| |
+----------+----------+ +------+------+
| | | |
[ ALLOCATED ] [ ASSIGNED ] [ Direct ] [ Reassigned / ]
PA / PI PA / PI Allocation Reallocated
ISP Pool vs Customer Site ISP Master Downstream
Enterprise Own Local Subnet Block Pool Customer Subnet
| |
+-------------+-------------+
|
[ Unified RDAP Standard ]
startAddress / endAddress JSON
2. Deciphering ARIN NetType vs RPSL Status
Determining the operational role of an IP block requires understanding how each registry conveys ownership status:
3. Normalizing Records with RDAP (JSON)
Modern network automation tools avoid fragile regex parsing of plaintext WHOIS by querying the unified RDAP interface:
Frequently Asked Questions
Why do ARIN and RIPE NCC use completely different object names for IP blocks?
RIPE NCC, APNIC, LACNIC, and AFRINIC use the Routing Policy Specification Language (RPSL, RFC 2622), where the primary IP address object is called "inetnum" (for IPv4) and "inet6num" (for IPv6). ARIN departed from RPSL in the 1990s, developing its own custom schema with "NetRange" and later RESTful XML/JSON interfaces (Reg-RWS).
What is the ARIN equivalent of RIPE's "status: ALLOCATED PA"?
In ARIN's database, the equivalent of ALLOCATED PA is "NetType: Direct Allocation". Both indicate that a large block was delegated to an ISP or LIR with full rights to sub-delegate smaller subnets to downstream customers.
What does "NetType: Reassigned" indicate in an ARIN lookup?
In ARIN, "Reassigned" indicates that an ISP carved out a portion of its Direct Allocation and assigned it to a specific customer or branch office without delegating administrative authority. The ISP maintains the parent allocation.
How does modern RDAP bridge the gap between inetnum and NetRange?
RFC 7483 standardizes the RDAP JSON schema across all five RIRs. In RDAP, both inetnum and NetRange are mapped to a uniform "startAddress", "endAddress", "ipVersion", and "entities" JSON hierarchy, removing regional syntax discrepancies for software developers.
Data & Technical Sources
- IETF RFC 2622 — Routing Policy Specification Language (RPSL)
- IETF RFC 4012 — Routing Policy System Extensions (inetnum attributes)
- ARIN Reg-RWS API Schema — RESTful Web Service payload models for ARIN NetRange