Summary

  • Norway's Brønnøysund Register Centre identifies TELEMIX AS as organisation 941 921 280, registered for wired, wireless and satellite telecommunications.
  • The RIPE Database assigns AS204996 the AS name TMNET and links it to Telemix AS through organisation ORG-TA1049-RIPE.
  • RIPEstat's 29 July 2026 snapshot shows 12 IPv4 prefixes, one IPv6 prefix, and visibility from every sampled IPv4 and IPv6 RIS peer reported by the endpoint.
  • The same snapshot observes AS2116 and AS34087 as routing neighbours; that is not proof of two independent physical paths or contractual redundancy.
  • Routinator-backed RIPEstat checks mark the captured origins valid for 45.67.8.0/22, 185.170.248.0/22 and 2a0a:ed00::/29.
  • Telemix advertises wireless and fibre broadband, but public number-resource records do not establish address-level availability, delivered speed, physical ownership or restoration practice.

One company appears in several public control layers

Telemix is unusually legible at the top of the network stack. A Norwegian company record identifies the legal organisation. RIPE registration data ties that organisation to a specific autonomous-system number. Route collectors then show what the number is doing in the public control plane. Route-origin authorisation records add a security-metadata layer, while the company's own website describes the services it offers to customers.

These layers reinforce one another without becoming interchangeable. The company registry answers who the legal organisation is. The RIPE Database answers which organisation is recorded against an autonomous-system assignment and what policy statements it has published. RIPEstat answers which prefixes and paths are visible through its collectors at a particular time. The website answers what the company says it sells. None of those sources alone describes the complete delivery chain.

That separation matters because internet infrastructure is often described with a single convenient label. Calling Telemix a local internet provider is consistent with its own presentation and legal activity code, but it does not reveal whether each service runs over owned fibre, leased capacity, wireless access, wholesale inputs or a combination. Calling AS204996 active is more exact at the routing layer, yet it does not show customer reach or physical continuity.

The strongest public conclusion is therefore layered rather than absolute. Telemix has a traceable legal identity and a visible number-resource identity. AS204996 is currently observed as a dual-stack routing origin. Several important aggregates have matching route-origin authorisation. The customer access boundary beyond that origin remains only partially documented.

This is the right starting point for infrastructure accountability. A registry should preserve unique, accurate records. Running routes should be measured as running routes. Commercial claims should remain attributed claims. Physical ownership, commissioning, capacity and resilience should be established separately instead of being inferred from the existence of an ASN.

The legal anchor is TELEMIX AS, organisation 941 921 280

The Brønnøysund Register Centre lists TELEMIX AS under organisation number 941 921 280. Its organisation form is an aksjeselskap, the Norwegian limited-company form. The entity was registered in the national Entity Register on 19 February 1995 and is also recorded in the Register of Business Enterprises and the VAT Register.

The principal industry code is 61.100, covering wired, wireless and satellite telecommunications. That code fits the company's current public description, but it remains a classification. It does not say which technologies are active at a particular customer address, which assets the company owns, or whether a given service is delivered directly or through another operator's facilities.

The registry gives a business address in Mo i Rana and reports 13 employees. Those fields help distinguish the exact legal organisation from similarly named businesses or brands. They should not be treated as an equipment inventory. A registered office is not automatically a network operations centre, a fibre point of presence, a radio site or the location from which services are physically delivered.

The exact legal identity is important because the routing record uses a shortened network name. AS204996 appears as TMNET, while the associated RIPE organisation is Telemix AS. Without the legal registry, a reader could mistake TMNET for a separate operator, a product or a historical label. The organisation number and legal name create a stable bridge between the company and its network identity.

Legal registration also has a limited continuity meaning. It shows that the organisation exists in the registry and is classified for telecommunications activity. It does not prove continuous operation of every advertised service, uninterrupted staffing, active maintenance of each route, or control of every physical component in the delivery chain. Those are operational questions.

The legal record is therefore an anchor, not a substitute for network evidence. It establishes the exact company to which later routing and service claims must be tied. It also prevents a common error in infrastructure reporting: assigning routes, facilities or service statements to a brand without first resolving the responsible legal entity.

AS204996 is the public routing identity

The RIPE Database records AS204996 with the AS name TMNET. The object references ORG-TA1049-RIPE, whose organisation name is Telemix AS and whose country is Norway. The autonomous-system assignment carries ASSIGNED status and was created on 23 November 2017.

An autonomous-system number identifies a routing policy domain. It gives other networks a stable number to place in BGP paths and gives operators a point of reference for origin policy, routing relationships and technical contact. It does not encode the size of the company, the number of customers, the physical reach of its access network or the quality of its service.

The difference between the AS name and legal name is normal. Short network identifiers are designed for operational use, while company registers preserve legal names. Here, the link through ORG-TA1049-RIPE makes the relationship explicit. TMNET is the AS name, and Telemix AS is the organisation attached to it.

The object also contains routing-policy statements. It records import and export lines involving AS16175, AS34087 and AS2116. Such lines are useful declarations of intended policy. They are not a live packet trace, an invoice, a contract or proof that every relationship is active exactly as written at the time of reading.

Registry timestamps carry the same distinction. The aut-num object was last modified in June 2020, while the captured organisation object shows a more recent modification in May 2026. A recent organisation update can improve confidence that someone is maintaining part of the record, but it does not validate every older policy line.

AS204996 is nevertheless a strong control-surface identifier. It lets observers ask concrete questions. Which prefixes originate from the ASN? Which collectors see them? Which neighbouring ASNs appear in paths? Are the origins covered by matching ROAs? Has the visible state changed? Those questions can be answered without claiming knowledge of the physical network hidden behind the routing boundary.

The current origin is visibly dual-stack

RIPEstat's AS overview marks AS204996 announced in the captured 29 July 2026 snapshot. Its announced-prefix endpoint lists 13 prefixes visible during the interval from 15 to 29 July: 12 IPv4 routes and one IPv6 route. The routing-status endpoint describes 3,072 announced IPv4 addresses and 524,288 IPv6 /48 equivalents.

The counts show a dual-stack public origin. They do not describe traffic volume, customer count or usable capacity. A /24 can contain 256 IPv4 addresses, but the number of addresses says nothing by itself about how many are assigned, how many customers use them, whether they sit behind carrier-grade NAT, or which services are reachable.

The IPv6 figure is even easier to misread. Counting /48 equivalents is a way to express address-space scale, not a statement that hundreds of thousands of customer networks are active. IPv6 allocation is deliberately spacious. The size of an announced aggregate cannot be converted into subscribers or deployed infrastructure without additional evidence.

The 13 listed routes also include both aggregates and more-specific prefixes. Counting every visible route as separate owned capacity would double-count parts of the same address space. The correct statement is that RIPEstat observed 12 IPv4 prefix entries and one IPv6 prefix entry for the origin during the captured interval.

Routing visibility is still operationally meaningful. It shows that AS204996 is not merely reserved in a registry. The ASN is present in the public control plane as an origin. Other networks can receive paths to its announced space, apply routing policy and evaluate route-origin authorisation.

That visible origin establishes a real operating surface, but only at the BGP layer. It says nothing about whether a packet reaching the AS boundary continues over fibre, fixed wireless, leased access or another arrangement. It does not establish where the customer handoff occurs or which company is responsible for each physical segment.

Full collector visibility is not the same as universal reach

The routing-status response reports visibility from 330 of 330 sampled IPv4 RIS peers and 324 of 324 sampled IPv6 peers. In that observation, AS204996's origin was visible to every full-feed peer counted by the endpoint for both protocol families.

That is a strong routing observation. It suggests that the origin was broadly propagated through the RIPE RIS collection view rather than appearing only through a small subset of peers. It supports the claim that the public origin is visible across the sampled control plane.

The denominator must stay attached to the conclusion. RIPE RIS peers are measurement points, not every network on the internet. Full visibility within the sample does not guarantee reachability from every user, every access network or every location. It also does not show application performance, latency, packet loss, filtering or congestion.

Collector visibility can remain high even when a local access problem affects customers. BGP may continue to advertise a prefix while a radio site loses power, an access switch fails, a fibre is cut after the handoff, or a customer authentication system stops working. The global route can look healthy while a service dependency is not.

The reverse is also possible. A collector may lose a path because of measurement topology or policy even though many customers continue receiving service. Route visibility is one layer of continuity, not the whole service.

For Telemix, the current result provides a useful baseline. AS204996 is widely visible through the sampled peers. A future reduction in visibility, change in originated prefixes or shift in neighbours would be measurable against that baseline. Explaining the cause would still require evidence from the operator, affected networks or physical systems.

Broad propagation therefore narrows uncertainty without eliminating it. It makes the BGP identity easy to observe. It does not turn the route collector into a coverage map or a service-level monitor.

Two observed neighbours define a routing edge, not physical redundancy

RIPEstat's neighbour endpoint identifies AS2116 and AS34087 as two observed left-side neighbours of AS204996. The routing-status endpoint also reports two observed neighbours. The two results are consistent in the captured snapshot.

An observed AS neighbour appears next to AS204996 in paths collected by RIPE RIS. That adjacency is a useful indicator of how routes enter or leave the visible routing domain. It is not a complete commercial classification. The path alone does not prove whether a relationship is paid transit, settlement-free peering, partial transit or another arrangement.

The aut-num policy object adds context because it contains statements involving AS2116 and AS34087. That agreement between declared policy and observed paths strengthens confidence that the adjacencies are not random name matches. It still does not reveal the terms, capacity, duration or physical implementation of the relationships.

Most importantly, two AS neighbours do not prove two independent failure paths. Both sessions could run through the same building, conduit, metro route, power system or upstream dependency. They could also be physically diverse while sharing a higher-level risk. Public AS paths do not expose those details.

Calling the network redundant would therefore go beyond the evidence. Redundancy requires knowledge of the failure being protected against. Separate BGP neighbours can help with routing continuity, but physical path diversity, power diversity, equipment separation and tested failover are distinct controls.

The neighbour result also should not be turned into a performance ranking. It does not say which path carries more traffic, which one is preferred, whether both are active for both protocol families, or how quickly policy converges during a failure. Those questions require telemetry that is not public here.

The defensible conclusion is narrower: RIPEstat observed AS2116 and AS34087 adjacent to AS204996 in its current view. They define a visible routing edge. The physical and contractual boundaries behind that edge remain unverified.

Registry policy is a statement of intent

The RIPE aut-num object includes import and export attributes. Such policy lines are part of the public routing registry and can help operators understand which routes an ASN intends to accept or announce to named networks.

These declarations matter because routing depends on coordinated policy. A network needs a way to communicate expected origins and relationships, and registries provide a durable place to publish that information. They reduce ambiguity for filters, diagnostics and incident response.

But policy text is not running code. A router can be configured differently from the registry. A relationship can change before the object is updated. A line can remain present after a session is retired, or a live session can be missing from an older declaration.

The current AS204996 record illustrates the need to compare layers. AS2116 and AS34087 appear in both the policy object and the observed neighbour view. AS16175 appears in policy statements but not in the two-neighbour RIPEstat snapshot. That difference is not proof that a policy is wrong. The collector may not observe every relationship, the session may be inactive, or the registry may reflect a broader arrangement.

The mismatch should not be resolved through guesswork. It is enough to say which networks appear in the registered policy and which appear in the sampled paths. A current operator statement or more complete route data would be needed to classify the status of AS16175.

This distinction supports a reality-layer approach to registry data. The registry is valuable as a ledger and coordination surface. Its authority lies in maintaining attributable records, not in overriding what routers actually announce. Running-code observations test the public manifestation of policy without making the registry irrelevant.

For Telemix, the combined view is stronger than either layer alone. The policy object names expected relationships. RIPEstat shows two current adjacencies. The unresolved differences identify monitoring questions rather than editorial conclusions.

RPKI gives three captured origins a valid authorisation state

RIPEstat's RPKI validation endpoint marks the captured AS204996 origin valid for three important aggregates: 45.67.8.0/22, 185.170.248.0/22 and 2a0a:ed00::/29. The endpoint reports Routinator as the validator.

A valid result means that the route's origin ASN and prefix length are consistent with a published Route Origin Authorisation. It answers a specific security-metadata question: is AS204996 authorised by the relevant ROA to originate that prefix at that length?

The details differ by aggregate. The ROA for 45.67.8.0/22 has a maximum length of /22, so the captured validation applies to that aggregate length. The 185.170.248.0/22 ROA permits more-specific announcements through /24. The IPv6 2a0a:ed00::/29 ROA authorises the /29.

That distinction matters because a parent aggregate and a more-specific route can have different validation outcomes. Saying that "AS204996 is RPKI valid" without naming a prefix hides the object that was actually checked. RPKI validity belongs to a prefix-origin-length combination, not to a company in the abstract.

Valid authorisation also does not mean the route is safe in every other respect. It does not prove that configuration is correct, that the holder's systems are secure, that the path is stable, or that traffic reaches the intended service. A correctly authorised route can still suffer leaks, congestion, operational mistakes or physical failures.

The ROAs nevertheless strengthen the public control surface. They give relying networks cryptographically verifiable metadata for rejecting conflicting origins under their chosen policy. They also make future changes auditable: a new origin, an overly specific route or an expired authorisation would produce a different result.

The appropriate conclusion is therefore precise. Three captured AS204996 aggregate origins have matching valid ROAs. That improves origin accountability at the routing layer. It does not certify Telemix's access network or service continuity.

The website describes a mixed access and services business

Telemix's website calls the company a local internet provider. It offers wireless broadband, fibre broadband and managed services, along with data cabling, fibre cabling, alarm systems and access-control work.

The broadband page advertises wireless speeds from 10/3 Mbps to 500/500 Mbps, depending on location. It advertises fibre tiers from 50/50 Mbps to 500/500 Mbps. The site also says customers can seek service through fibre or radio.

These statements are valuable because they come from the company and describe its current commercial positioning. They connect the legal and routing identity to a claimed customer-facing role. They remain first-party offers rather than independent measurements.

The phrase "depending on location" is an important boundary. It acknowledges that availability varies, but it does not publish an exact serviceability matrix. A headline speed cannot be applied to a particular home, business or community without an address-level qualification.

The website's language about local expansion and tailored solutions also should not be converted into a completed asset claim. A statement that a network is being expanded does not identify which segment is designed, installed, energised, commissioned, commercially available or carrying customer traffic.

The mix of wireless and fibre creates additional ambiguity at the physical layer. A customer service could use a radio access link with fibre upstream, a fibre access circuit with leased middle-mile capacity, or another combination. The public BGP origin does not distinguish among those architectures.

Attributing the offer is therefore more accurate than endorsing it. Telemix says it provides local broadband over wireless and fibre and advertises specified speed ranges. The public sources here do not independently verify delivered throughput, customer totals, availability, asset ownership or performance under failure.

Advertised speed is not installed or usable capacity

Broadband speed tiers are reader-friendly, but they are easy to confuse with network capacity. A 500/500 Mbps product describes a possible customer service profile. It does not show how much aggregate capacity is installed, how many customers share an upstream, or how much headroom is available at peak demand.

Physical capacity passes through several milestones. Equipment can be designed for a rate without being installed. Installed equipment can remain unpowered. Powered equipment can remain uncommissioned. A commissioned link can have capacity that has not been sold, and sold capacity can be constrained by another shared dependency.

The Telemix website does not provide that milestone chain. It presents service tiers and general technology descriptions. Those are appropriate commercial statements, but they cannot support a claim about the size of the backbone, the capacity of a radio sector, the utilisation of an uplink or the throughput of a specific fibre route.

BGP data does not fill the gap. Prefix count and address space are identifiers, not bandwidth. Two upstream-looking neighbours do not reveal port sizes. Full collector visibility says nothing about congestion. RPKI validity says nothing about performance.

Even symmetric product labels require context. A symmetric tier may refer to configured access rates under normal conditions, while actual throughput can depend on customer equipment, radio conditions, oversubscription, upstream capacity and protocol overhead. None of those dependencies appears in the number-resource records.

This does not make the advertised tiers meaningless. They establish what the company offers prospective customers and provide a reference for service-specific testing. The responsible next question is whether a quoted address and installed connection are provisioned for the stated tier, not whether the ASN is large enough to make the claim plausible.

Keeping product speed separate from physical capacity protects both readers and operators. It prevents a commercial offer from becoming an unsupported network-wide engineering assertion.

Public routing does not reveal the last-mile handoff

AS204996 shows where Telemix's public routing identity becomes visible. It does not show where a customer circuit enters that routing domain or which organisation controls each segment before it reaches the origin.

For a fibre customer, the path could include building cabling, an optical termination, an access splitter, local distribution fibre, a handhole or cabinet, aggregation equipment and a middle-mile handoff. For a wireless customer, it could include customer-premises radio equipment, a tower or rooftop site, spectrum conditions, backhaul and power at the access site.

The public sources do not map those dependencies. The website demonstrates that Telemix markets both access modes, but it does not tie a particular route, prefix or customer to a specific physical chain. The RIPE records begin at the number-resource and interdomain-routing layers.

Ownership can vary along the chain. Telemix may own some assets, lease others, use wholesale transport or contract installation. Without exact source evidence, assigning ownership to every visible or implied component would be speculative.

The handoff matters when responsibility is tested. A customer outage caused by in-building wiring is different from a radio backhaul failure. A cut in leased middle-mile fibre creates a different recovery path from a failure inside an owned aggregation node. The same public ASN can sit above all of those possibilities.

This is why the visible routing identity should not be drawn as the physical network. AS204996 is a control-plane boundary. It helps locate origin accountability and routing relationships. It does not disclose the complete chain from a customer device to the public internet.

The unresolved handoff is not a weakness in the analysis. It is a precise statement about where public evidence stops. It also defines the most useful future disclosure: the operator could explain which segments it owns, which are leased, where service responsibility changes and how failures are escalated across those boundaries.

Two routing neighbours do not settle the resilience question

Resilience is not a count of ASNs. It is the ability of a service to continue or recover when a defined dependency fails. The two neighbours observed for AS204996 are relevant, but they are only one part of that question.

If the two sessions use separate upstream networks but share one local fibre, a cut to that fibre can disable both. If they enter the same facility and depend on one power system, a facility event can remove both paths. If they are physically diverse but configured under a common control mistake, policy can still withdraw both.

Conversely, one visible upstream ASN can provide multiple circuits, diverse entrances or several regional paths. The public AS path would not show all of that physical detail. Counting neighbours can therefore understate or overstate the actual engineering arrangement.

Protocol family matters too. A neighbour observed in aggregate data may not provide equivalent IPv4 and IPv6 paths or may be preferred differently. Public material does not expose session-level policy, traffic engineering, failover timing or capacity.

Operational resilience also extends beyond transit. DNS, authentication, customer provisioning, monitoring, support communications and local power can fail while BGP remains stable. A route collector would continue to see the origin even if a reader could not use the service.

No public failover test is available here. There is no dated incident report showing how Telemix switched paths, restored a radio site or rerouted around a fibre cut. There is therefore no basis for claiming tested redundancy or a particular recovery time.

The two-neighbour observation remains useful as a routing fact. It gives a baseline for change and identifies external networks that appear adjacent in the sampled view. The resilience conclusion must stop there: the visible routing edge has two neighbours, while physical diversity and service recovery remain unverified.

RPKI protects origin intent, not the entire service

RPKI is often described as a security control, but its protection is deliberately narrow. A valid ROA helps networks determine that a particular ASN is authorised to originate a particular prefix at an allowed length.

That control addresses one important failure class: an unauthorised or incorrectly originated route can be marked invalid under route-origin validation. Networks that enforce an appropriate policy can reject or de-prioritise such announcements.

RPKI does not validate the AS path beyond the origin. It does not prove that every routing-policy decision is safe, that an authorised operator has not made a mistake, or that traffic will follow the expected physical route. It also does not inspect application security or customer data.

For AS204996, the valid results show that Telemix's captured origins for the three checked aggregates align with published authorisation. That is positive, measurable security metadata. It should not be stretched into a general statement that the network is secure.

The maximum-length fields are operationally significant. A more-specific route can become invalid even when its parent aggregate is authorised, depending on the ROA. Operators need to maintain those fields as routing designs change. A stale or overly restrictive ROA can turn a legitimate announcement into an invalid one.

Continuity therefore depends on maintenance as well as initial publication. Registry access, certificate renewal, route planning and deployment procedures all have to remain coordinated. The source records do not describe Telemix's internal controls for that work.

The appropriate public accountability statement is balanced. AS204996 has valid route-origin authorisation for the checked aggregates, improving origin verifiability. The rest of the service chain, from path selection to physical access and customer application performance, requires different controls and evidence.

Operational continuity includes people and procedures

Number-resource and routing records describe technical identifiers, but continuity also depends on people who can act. Someone must maintain registry access, router configuration, RPKI certificates, monitoring, customer communication and supplier escalation.

The RIPE organisation object provides administrative structure and an abuse-contact reference. The company website provides public contact channels and presents a local support role. Those surfaces improve traceability, but they do not reveal staffing schedules, escalation authority or tested recovery procedures.

Employee count is not a continuity metric. A small team can operate a reliable network with automation and strong suppliers; a larger team can still have concentrated knowledge or fragile procedures. The Norwegian registry's count of 13 establishes scale only in a broad legal-record sense.

Local service can create both strengths and dependencies. Proximity may shorten communication paths and improve knowledge of terrain. It can also concentrate staff, equipment or suppliers in one region. The sources do not establish which effect dominates for Telemix.

Continuity planning would normally address loss of an upstream, access-site power failure, fibre damage, radio interference, configuration error, credential loss and supplier unavailability. Public BGP data can show some consequences, but it does not show whether runbooks, spares or authority are in place.

RPKI adds another procedural dependency. Someone must keep authorisations aligned with routing. The company registry and RIPE account must remain under responsible control. A mismatch can create a routing problem even when the physical network is healthy.

The public identity is therefore necessary but incomplete. Telemix can be reached through legal, registry and service surfaces, and AS204996 is visible in running routes. Operational continuity asks whether those surfaces remain coordinated under stress. No public test result answers that question here.

A service footprint needs address-level evidence

Telemix says it offers fibre and wireless broadband, with availability depending on location. That phrase correctly points toward an address-level qualification process.

A service footprint should be based on where an operator can actually accept an order and deliver the stated product. A broad regional identity, a local office or a public ASN cannot establish that boundary. Coverage can vary street by street for fibre and by terrain, line of sight and radio design for wireless access.

The website does not provide a machine-readable current coverage map in the captured pages. Even if it did, a marketing map would need qualification because planned, buildable, installed and orderable areas are not the same.

For fibre, a route near a property does not mean a drop is available. Construction permissions, spare ports, distribution design and installation work can determine whether service is deliverable. For wireless, nominal signal reach does not guarantee a usable link through terrain, buildings or interference.

AS204996 cannot supply the missing geography. BGP routes describe reachability to address prefixes at an interdomain level. They do not encode where subscribers live or which access technology reaches them.

The advertised speed tiers similarly need serviceability context. A customer quote, installation record or address checker can establish what is offered at a location. Independent measurement can then establish delivered performance. Those are different evidence steps.

The accurate public statement is therefore attributed and conditional: Telemix markets fibre and wireless broadband and publishes speed ranges that depend on location. No broader address-level availability or delivery claim follows from the legal and routing records.

The physical failure path remains outside public view

Every service has a chain of dependencies. For a regional provider, that chain can include customer equipment, access plant, aggregation, backhaul, upstream routing, DNS, authentication, power, monitoring and support.

The public sources make the upstream routing layer visible but leave most of the chain undocumented. If a prefix disappeared from RIPE RIS, observers could see a control-plane change. They could not identify the failed fibre, radio, router, power source or procedure from that change alone.

The same limitation applies when routes remain visible. A local access fault can affect a group of customers without changing the origin seen by global collectors. The physical failure path can be narrower than the routing domain.

Ownership affects recovery. An operator can repair owned equipment directly, while a leased circuit may require escalation to a supplier. A shared site can involve a landlord, tower operator or power provider. Public routing relationships do not identify those parties.

No dated outage or restoration record is included here. It would be irresponsible to invent a likely cause or imply that a visible update burst represents a failure. A proper incident analysis would need a start time, affected boundary, operator statement, route and health observations, recovery action and end time.

What can be said is that the public accountability surface is ready for such analysis. AS204996, its prefixes, neighbours and ROA state can be checked. The legal company and contact surfaces are known. Missing physical details can be requested rather than assumed.

That division is useful for readers. It shows what can be monitored independently and what depends on operator disclosure. It also prevents a clean routing chart from being mistaken for proof that the underlying service is resilient.

The registry is a ledger, not a sovereign description of reality

RIPE's records are essential because they preserve unique number-resource assignments, organisation references and policy statements. That ledger function makes the internet easier to coordinate and audit.

The records should not be treated as a complete description of the operating network. A registry cannot see every router configuration, physical asset, commercial agreement or customer experience. Its authority comes from keeping attributable records, not from replacing running-code evidence.

AS204996 demonstrates the value of combining both layers. The registry connects TMNET to Telemix AS. RIPEstat shows that the ASN is announced, broadly visible and adjacent to two observed networks. RPKI validation shows that selected origin statements match published authorisation.

The running-code view also has limits. A collector sees paths, not the full physical service. It cannot decide who owns a fibre, whether a radio link is commissioned, or how quickly a team can restore a failed dependency. Observability is not sovereignty either.

First-party service claims add another layer. They explain the products Telemix offers but do not independently verify delivery. The legal registry confirms the company but does not certify performance. Each source is strongest when used for the question it is designed to answer.

This layered method avoids two opposite errors. It does not dismiss registry data as mere paperwork, and it does not elevate registry status into proof of current service. It does not dismiss BGP as too technical, and it does not turn BGP visibility into a physical network map.

The result is a more durable company profile. Telemix has a legal and operational identity that can be tracked. The public routing surface is visible and partially secured by RPKI. The physical delivery and continuity boundary remains a legitimate subject for further evidence.

What public accountability can establish today

Several conclusions are well supported. TELEMIX AS is an exact Norwegian legal company with telecommunications as its registered activity. The RIPE Database links that organisation to AS204996 under the name TMNET. The ASN is currently announced in RIPEstat.

The origin is dual-stack. RIPEstat lists 12 IPv4 prefix entries and one IPv6 prefix entry in the captured interval. Visibility is reported from all sampled full-feed peers counted by the endpoint for both protocol families.

AS2116 and AS34087 are the two observed neighbours in the current RIPEstat view. They define a visible routing edge but do not prove commercial terms or physical diversity.

The checked aggregates 45.67.8.0/22, 185.170.248.0/22 and 2a0a:ed00::/29 validate as RPKI valid for origin AS204996 under the captured Routinator-backed checks. That is a concrete route-origin security property.

Telemix publicly offers wireless broadband, fibre broadband and managed services, with advertised tiers and location-dependent availability. Those statements can be attributed to the company.

The unresolved fields are equally clear. There is no verified map of owned access assets, no address-level serviceability result, no independent speed measurement, no physical upstream diagram, no tested failover evidence and no public restoration record in the captured sources.

This balance is more useful than a generic company description. It tells readers what they can independently verify and what they cannot. It identifies a real network control surface while refusing to invent the physical network behind it.

The next disclosure should connect control plane to delivery

Telemix could make its operating boundary clearer without publishing sensitive configuration. A high-level description of owned versus leased access and transport would help readers understand responsibility without revealing exact routes.

The company could also explain how fibre and wireless serviceability is qualified. Separating areas that are planned, buildable, installed, commissioned and currently orderable would prevent broad expansion language from being mistaken for universal availability.

A resilience statement should identify failure classes rather than simply count upstreams. Physical path separation, site power, spare equipment, monitoring and supplier escalation can be described at a high level. Evidence of tested failover would be more informative than the number of BGP neighbours.

RPKI maintenance is another useful transparency point. Telemix need not expose credentials or internal procedures to state that route-origin authorisations are reviewed when prefix policy changes. The current valid results provide a positive baseline.

Incident communication can connect the layers during a real event. A notice that names the affected access boundary, start time, customer impact and recovery state can be compared with public route observations. That helps distinguish a local access fault from a wider routing event.

None of these disclosures is required to recognize the current network identity. AS204996 is already visible and attributable. They would instead explain how the visible routing domain relates to the service customers receive.

The most important next step is therefore not a larger list of prefixes. It is a bounded account of the handoff between number resources, routing policy and physical delivery. That is where operational responsibility becomes tangible.

A visible origin is a beginning, not a complete infrastructure claim

Telemix AS has more public network evidence than a generic business profile. The legal company is identifiable. The ASN is assigned and active in the routing table. The dual-stack origin is widely visible in the sampled view. Two neighbours can be observed, and key aggregates carry valid route-origin authorisation.

Those facts deserve to be reported because they make the company's internet control surface concrete. They also make future changes measurable. A new prefix, neighbour shift, visibility loss or RPKI change can be compared with an exact baseline.

The same facts impose limits. They do not prove that Telemix owns the last-mile infrastructure implied by its service offers. They do not establish where fibre is lit, where radio service is orderable, how capacity is shared or what happens when a physical dependency fails.

The first-party website closes part of the commercial gap by describing fibre and wireless products. It does not close the engineering gap. Advertised tiers are not installed capacity, and local-provider language is not a service-area map.

The responsible picture is therefore neither promotional nor sceptical. Telemix has an observable legal, registry, routing and RPKI identity. Its customer delivery boundary remains less visible than its public origin.

That distinction follows the infrastructure rather than the brand. It treats the registry as a coordination ledger, routes as running code, ROAs as origin-security metadata and service claims as attributed offers. It leaves physical ownership, capacity and resilience to evidence that can actually establish them.

AS204996 makes Telemix's public routing domain visible. The unresolved question is how that domain is connected, powered, maintained and restored at the access edge. Until those dependencies are documented, the visible origin should be understood as the beginning of the operating story, not its conclusion.

Sources