Summary

  • AS216429 (as-name NETMAX-BRO-LTD) entered the RIPE database on 22 September 2025 under organisation ORG-NMBL1-RIPE — NET MAX BRO LTD of Majdal Shams, Israel, itself created on 18 September 2025 — with K.M.A ADVANCED TECHNOLOGIES LTD of Arara, Israel, acting as sponsoring LIR, record maintainer and registered administrative and technical contact.
  • The network originates two prefixes, 154.9.155.0/24 and 2a07:5680:4::/48, totalling 256 originated IPv4 addresses, with exactly one observed BGP peer — AS212616, the K.M.A network that also sponsors it — and no observed downstream networks.
  • The IPv4 /24 is not space the registered holder owns. It lies inside ARIN Direct Allocation NET-154-9-0-0-1 (PSINET-B2-9, 154.9.0.0/16, registered on 5 February 1992), attributed to Cogent Communications, LLC; the operational join is a RADB route object maintained by Cogent's own engineering identity (MAINT-AS174) and changed on 21 October 2025 — 33 days after the organisation's registration — describing the space as registered for Cogent customer K.M.A Advanced Technologies LTD.
  • RPKI coverage is asymmetric: the announced IPv6 /48 carries a valid RIPE-repository ROA; the announced IPv4 /24 carries no ROA; and a second ROA, for 2a05:dfc1:8700::/40 under Cloudie's repository, covers a prefix that is not observed announced at all.
  • No registry or routing fact establishes what this network is for. What the file establishes is the mechanism: how a globally visible routing presence can be assembled in weeks out of other parties' address space, permissions and transit — and why the routing table, not the registry, is the only ledger that speaks for itself.

Three ledgers, and why they must be read apart

Number resources acquire identities the way institutions acquire histories: one ledger at a time. A registry ledger records who holds what. An authorisation ledger records who is entitled to route it. The routing table records what is actually being announced, updating within minutes while the other two change over months or decades. For a conventional network — a regional ISP that owns its address space, employs its own engineers and peers at several exchanges — the three ledgers tell one story from three angles, and nobody examines the joints.

AS216429 invites exactly that examination, because its three ledgers name three different sets of parties:

  • Registration names NET MAX BRO LTD, a company registered in Majdal Shams on 18 September 2025, holding AS216429 since 22 September 2025, with every visible registry function performed by its sponsor, K.M.A ADVANCED TECHNOLOGIES LTD.
  • Authorisation names Cogent Communications, LLC, the holder of the ARIN /16 containing the announced /24, whose engineering identity maintains the route object that makes the announcement acceptable to IRR-reliant networks.
  • Demonstrated operation shows a two-prefix network whose sole observed dependency is AS212616 — the sponsoring LIR's own autonomous system — riding which the /24 and the /48 reach the rest of the internet.

Each layer, read alone, produces a different answer to the question "who is this network?" Only together, with their boundaries marked, do they produce an honest one. The capture date for all evidence below is 27 September 2026. All registry facts rest on mirrored copies of RIPE and ARIN database records and on public routing-observation platforms, each named where cited. The authoritative registry endpoints were queried during this pass but did not return inspectable record bodies — a limitation stated in full, with its consequences, at the end of the file.

Ledger one: registration

The RIPE record for AS216429, as reproduced by third-party mirrors of the RIPE database, is compact and unambiguous about its own contents. The aut-num object carries as-name NETMAX-BRO-LTD, organisation ORG-NMBL1-RIPE, sponsoring organisation ORG-KTCL1-RIPE, status ASSIGNED, and maintenance by lir-il-kmatechnology-1-MNT, with creation timestamp 2025-09-22T10:24:28Z. The organisation object behind it, ORG-NMBL1-RIPE, names NET MAX BRO LTD, organisation type OTHER, located in Majdal Shams, Israel, under company registration number 516319878; it was created on 2025-09-18 — four days before the AS — and was last modified on 2026-05-13, nearly eight months later, which shows the record has remained an actively maintained object rather than a one-time filing. The role object recorded as both administrative and technical contact, CA10383-RIPE, belongs to K.M.A ADVANCED TECHNOLOGIES LTD of Arara, Israel IPIP.net's mirror of the RIPE objects.

Every externally visible handle on the registration therefore resolves to one company other than the registered holder. The sponsor, ORG-KTCL1-RIPE, is the organisation behind AS212616 (as-name KMA-Technology), an operating LIR whose own autonomous system was registered on 2021-10-25 and which, per the mirrored record, is registered in Arara under company number 515949592 IPinsight's mirror of the AS212616 record. The same company occupies the sponsor, maintainer, admin-c and tech-c positions on the new organisation's AS object. In the RIPE registration model, an end user obtains number resources through a sponsoring LIR; here the model is functioning exactly as designed, with the twist that the end user was four days old at registration and has no separately visible operational identity anywhere in the record.

What does this ledger prove? That on 22 September 2025, a company four days old became the registered holder of an autonomous system number through a sponsorship arrangement whose entire visible apparatus belongs to the sponsor. What does it not prove? That any router existed anywhere; that any prefix was ever announced; that the holder employs engineers, operates a network operations centre, or controls a single decision in its own registration. A registry row is a database claim. It is the weakest of the three ledgers — and the one most often mistaken for the whole story, because it is the easiest to read.

The record does contain one forward-looking statement: a declared routing policy importing routes from AS212616 and AS1680 and announcing AS216429 to both RTSAK's mirror of the routing policy. Declared policy is intent, not fact. Import and export lines in a registry describe what the holder says its relationships are; the global routing system only ever shows which of those declarations were made true — and, in this case, by whom.

Ledger two: authorisation

Registration makes an AS number exist. It does not make a single prefix routable. For that, address space is required — and 154.9.155.0/24, the IPv4 prefix AS216429 announces, is where this file stops being a routine registration note and becomes a cross-registry case.

The /24 is a component of 154.9.0.0/16. ARIN's own record for the parent block — handle NET-154-9-0-0-1, NetName PSINET-B2-9 — lists 154.9.0.0/16 as a Direct Allocation to Cogent Communications, LLC (COGC), registered on 5 February 1992 and last updated on 23 September 2025 ARIN's whois record for NET-154-9-0-0-1. A commercial mirror of the same allocation attributes the /16 to Cogent Communications and places the /24 inside it, with the /24's registration living in the ARIN registry rather than with the announcing party ipregistry's view of the Cogent /16. No ARIN object attributing the /24 to NET MAX BRO LTD or to K.M.A was observed anywhere in the captured material.

So how does a RIPE-registered AS in Israel announce a slice of an ARIN allocation held by an American transit provider? The join is documented, and it is not held by the registered owner. Hurricane Electric's per-prefix view of 154.9.155.0/24 states the split explicitly: origin AS216429 (NET MAX BRO LTD), prefix registrant Cogent Communications, LLC. The operational link is a RADB route object — route: 154.9.155.0/24, origin: AS216429 — whose description reads "Route Registered for Cogent Communications Customer - K.M.A Advanced Technologies LTD", maintained by MAINT-AS174, Cogent's own maintainer identity, and changed by Cogent's network engineering on 21 October 2025. The same page records the covering announcements that make the /24 globally sensible: AS174 for 154.9.0.0/16 and AS36947 for 154.0.0.0/12 Hurricane Electric's prefix view of 154.9.155.0/24.

Read as a chain, the authorisation for this file's most consequential announcement runs: ARIN allocated the /16 in 1992; the block is attributed to Cogent Communications, LLC; Cogent's engineering identity maintains a RADB object naming its customer K.M.A Advanced Technologies LTD; K.M.A sponsors AS216429 and is its transit; AS216429 originates the /24. Four links, three of them controlled by parties other than the registered holder. The RADB object — the /24's only observed authorisation instrument — is created, edited and withdrawable by Cogent. The AS object itself is maintainable by the sponsor.

NET MAX BRO LTD holds the origination act and nothing else. It is also worth dating the construction precisely: the object that made the announcement acceptable was changed on 21 October 2025, thirty-three days after the organisation's registration and twenty-nine days after the AS. This was not an inherited arrangement. It was assembled, quickly, within a month of the holder coming into existence.

Mirrors complicate the picture in an instructive way. A third-party copy of the /16's whois data still displays the organisation as "Performance Systems International (PSI-24)" with a December 2021 update stamp — the name under which the PSINET space was registered decades ago — while current ARIN records show Cogent Communications, LLC with a 23 September 2025 update IPIP.net's mirrored /24 whois page. Same block; different decades; different names. Mirror data lags, which is why this file flags it wherever it leans on a mirror rather than a primary record.

Ledger three: demonstrated operation

The third ledger owes nothing to paperwork. Public routing observation — the same evidence class that detects route leaks and hijacks — shows AS216429 originating exactly two prefixes: 154.9.155.0/24 and 2a07:5680:4::/48, together 256 originated IPv4 addresses, with exactly one observed BGP peer, AS212616, and more than 600 observed AS paths in each address family (680 in IPv4, 639 in IPv6) on Hurricane Electric's collectors Hurricane Electric's AS216429 page. CIDR Report's adjacency analysis independently classifies the network as ORIGIN-only: one upstream adjacency, zero downstreams, 256 addresses originated, zero transit, with a concrete observed path — 4777 2497 1299 1680 212616 216429 — showing the /24 propagating through at least four networks above the sponsor before reaching global vantage points CIDR Report's AS216429 report.

The topology is narrow by construction, and its narrowness is informative. Relationship classifiers, including IP2Location, place AS212616 as AS216429's upstream IP2Location's AS216429 record. IPinfo's view of AS212616 shows that network's own upstreams as AS1680 (Cellcom Fixed Line Communication L.P) and AS208905 (Exelera Telecom Ltd) IPinfo's AS212616 page. Hurricane Electric's AS212616 page shows a substantially larger network — 70 originated prefixes (40 IPv4, 30 IPv6) and 16 observed peers — and reproduces the reciprocal policy between the two ASes: AS212616 imports from AS216429 and announces AS212616 to it, the provider-side mirror of the customer relationship Hurricane Electric's AS212616 page. Assembled, the picture is consistent: a small customer AS whose one transit is also its sponsor, whose sponsor in turn rides Israeli and international upstreams, and whose IPv4 reachability ultimately depends on Cogent's global transit one more layer up.

Even the thin footprint is recorded inconsistently at the edges. IPGeolocation's mirror lists both AS1680 and AS212616 as peers of AS216429, shows one route in each family, and carries an abuse contact for the AS pointing at the sponsor's domain, kma.net.il IPGeolocation's AS216429 record — a broader peer set than Hurricane Electric's single observed peer, and another reminder that even the abuse channel of the AS runs to the sponsor. The reputation database NERD created its record for 154.9.155.0/24 under AS216429 on 13 July 2026 and last updated it on 24 July 2026 NERD's AS216429 entry.

None of these variations changes the core finding: demonstrated operation exists, is measurable, and is minimal. Two prefixes. One dependency. No downstreams. A network that is genuinely on the internet — the routing table does not lie about that — while revealing nothing else about itself.

The RPKI asymmetry

RPKI, the cryptographic attestation layer that increasingly determines whether routes are accepted, cuts this file into an unusually sharp pattern. A validator listing of ROAs for AS216429 shows two authorisations: 2a07:5680:4::/48 with maximum length 48, signed in the RIPE RPKI repository, and 2a05:dfc1:8700::/40 with maximum length 48, signed in the Cloudie RPKI repository rpki-client's validator output for AS216429. The live per-ASN view marks the two announced prefixes differently: 2a07:5680:4::/48 is RPKI VALID for origin AS216429, while 154.9.155.0/24 is NOT-FOUND — no ROA exists for it ping.pe's per-ASN table.

Three consequences follow. First, the network's IPv6 presence is origin-validated: the /48 is covered by an authorisation in the same registry family as its registration and will survive filtering regimes that reject unvalidated routes. Second, the IPv4 /24 — commercially the more valuable half, being legacy IPv4 — has no cryptographic authorisation at all; its acceptance depends on IRR route objects, the voluntary and editable class of record, and on the filtering policies of the networks it transits.

Third, the Cloudie-repository ROA for 2a05:dfc1:8700::/40 authorises a prefix that none of the routing observers cited above show as announced. An authorisation without an announcement could indicate planned use, stale routing data, or an authorisation whose relationship to this file's subject is other than it appears; the captured evidence cannot distinguish these, and the file does not guess.

The asymmetry also defines the network's vulnerability. The /48 is robust. The /24 lives at the pleasure of a RADB object maintained by another company's engineers. If that object were withdrawn, networks relying on IRR filtering would lose their basis for accepting the /24, and with no ROA to fall back on, the IPv4 announcement would likely be filtered out of large portions of the global table. The registered holder has no instrument with which to reconstitute it.

Three platforms, three answers

A due-diligence question that sounds simple — "is this network operating?" — receives different answers depending on where it is asked. IPinfo's ASN summary for AS216429 lists the network as Business type, RIPE registry, allocated 22 September 2025, with 0 IPv4 routes — alongside 256 IPv4 addresses and roughly 1.21 × 10^24 IPv6 addresses attributed to it IPinfo's AS216429 summary. Four other platforms consulted in the same research pass — IPGeolocation, ping.pe, Hurricane Electric and CIDR Report, each cited above — show the /24 announced with origin AS216429. ipregistry's record adds a second IPv6 range to the network's attribution, 2a05:dfc1:8700::/40 registered to Cloudie Networks, and states that AS216429 has no direct peering agreements, reaching the internet instead through at least one transit upstream ipregistry's AS216429 record.

These are not exotic discrepancies. Aggregators sample different route collectors at different moments, apply different definitions of "route", and refresh on different schedules. But the disagreement is itself evidence — of data-vintage differences, and of how much interpretation sits between a BGP table and an AS profile page. For anyone making decisions based on a profile page, the lesson of this file is that the profile is not the network: the collectors' raw view and the registry instruments behind it are the only material worth weighing.

What no ledger establishes

The most important content of this file is what it cannot establish.

What runs on the 256 addresses is not in the record. Research across public network databases surfaced no independent PeeringDB record for AS216429 — and the absence of a surfaced record is not evidence that none exists. No customer-facing service was identified. No contract, letter of authorisation or assignment record between Cogent, K.M.A ADVANCED TECHNOLOGIES LTD and NET MAX BRO LTD appears in the captured material; the commercial chain is evidenced only by the customer-of reference inside the RADB object and by the shared role contacts described above.

Commercial intent — address leasing, resale, a testbed, a customer build-out, or something else entirely — is not a registry fact or a routing fact, and this file asserts none.

The structure, however, is legible and worth naming precisely. A newly created organisation; sponsorship by an LIR that is simultaneously its only transit; a /24 carved from a transit provider's own legacy ARIN aggregate; authorisation held in a route object that the provider's engineers maintain; a footprint of exactly two prefixes with one peer. This is the structural shape of provider-separated routing: a routing identity whose holder does not own the address space, does not hold the authorisation and does not deliver the transit.

That shape is the ordinary supply of the leased-address and bring-your-own-IP market, where continuity of routing identity is deliberately separated from the network that delivers traffic. Observing the shape is evidence about the market's mechanics. It is not evidence about this party's motive, and the two must not be quietly swapped — which is exactly the swap that most coverage of unusual-looking ASNs performs by default.

Institutional framing deserves one explicit line. RIPE NCC and ARIN have published no position on this specific resource in the material reviewed. Where this file says "the RIPE database shows" or "ARIN's records list", it reports the content of those databases as recorded in the mirrors consulted — it does not treat the registries' framing as authority over the observed routing record, and it weighs database entries against what the routing system actually does rather than the other way around.

How to read this file

The evidence in this case file was captured on 27 September 2026 through public web research. Its composition is deliberate and its limits are real.

Registry facts — registration dates, organisation fields, contacts, maintainers — come from third-party mirrors of the RIPE database, including the mirrors already cited, plus additional aggregator views such as theipapi.com's AS216429 record. The two authoritative lookups this research attempted directly — the RIPE RDAP endpoint for the autonomous system, rdap.org/autnum/216429, and the ARIN RDAP endpoint for the announced /24, rdap.arin.net/registry/ip/154.9.155.0 — did not return inspectable record bodies during the pass. The registration and allocation facts above are therefore provisional until re-verified against those authoritative servers; the file states this rather than pretending otherwise.

Routing and reputation facts come from observation platforms: the per-ASN and per-prefix views already cited, plus prefix-scoped mirrors such as ping.pe's record for 154.9.155.0/24 and further routing-intelligence views of the upstream network such as bgp.tools' AS212616 page. Observations are snapshots. A route announced today can be withdrawn tomorrow without any database anywhere changing; a database can be edited without the routing system noticing.

The load-bearing distinction this file asks its readers to carry is simple. Registration is what a database says. Authorisation is what a third party permits. Operation is what the routing system shows. AS216429 demonstrates all three, arranged so that the registered owner depends on its sponsor for existence, on Cogent for the acceptability of its IPv4, and on AS212616 for its entire reachability.

Whether that construction is a routine service arrangement or something more unusual is exactly the kind of question that cannot be answered from any single ledger — which is why this file declines to answer it, and instead documents, with dates and numbers, where each ledger ends.

A structured directory record for this entity, including BTW's claim layer on these facts, is maintained at BTW's directory entry for NETMAX-BRO-LTD.