Summary

  • RIPE RDAP binds AS42675 and the name OBEHOSTING to registrant organisation ORG-OA1026-RIPE, Obehosting AB, at an address in Älvsjö, Sweden.
  • RIPEstat lists 20 current origins for AS42675: 11 IPv4 prefixes and nine IPv6 prefixes. The routing-status view reports 6,656 IPv4 addresses and 524,296 equivalent IPv6 /48 units.
  • The current RIPE RIS sample sees the IPv4 origin set through 330 of 330 peers and the IPv6 origin set through 324 of 324 peers. Visibility describes control-plane propagation, not service availability or customer reach.
  • A bounded RPKI check for 46.227.64.0/21 originated by AS42675 is valid under Routinator, with a matching maximum length of 21. The result applies to that tested prefix and must not be generalized to the other 19 routes.
  • RIPEstat observes one left-side BGP neighbour, AS3399. The public path observation does not establish the commercial relationship, physical route, exclusivity, failover design or contractual dependency.
  • Obehosting's public-facing Obenet page describes broadband for individuals and companies and names fibre, municipal networks and a backbone. Those are first-party service descriptions, not independent proof of footprint, capacity, uptime or resilience.

A company, an ASN and a public operating surface

The most reliable starting point is the identity bridge between a company record in the BTW directory and a unique Internet number resource. The directory identifies the company as OBEHOSTING Obehosting AB. RIPE's RDAP response for autonomous system 42675 uses the name OBEHOSTING and names Obehosting AB as the registrant organisation. The organisation handle is ORG-OA1026-RIPE.

This is more than a loose brand match. The RDAP card records Obehosting AB as an organisation at Massvägen 4, 125 30 Älvsjö, Sweden. It also lists Obenet NOC as the administrative, technical and abuse contact, with [email protected] as the abuse mailbox. The public company identity, network name, operating contact and domain therefore form a reproducible chain.

RIPE's member directory provides a second institutional signal. It lists Obehosting AB as a Swedish RIPE NCC member. Membership says that the organisation participates in the regional Internet registry's service framework. It does not grant a quality mark for the company's services, certify physical ownership, or prove that the public contact data is always current.

The autnum entity was registered on 23 July 2018 and last changed on 1 March 2021. These dates belong to the registry record. They are not dates for a data-centre opening, the installation of a fibre path, the start of customer service or the commissioning of a backbone. Registry chronology and operating chronology should remain separate.

The result is a precise but bounded identity. AS42675 can be monitored as Obehosting's public routing surface. The ASN cannot stand in for every product, facility or contractual obligation associated with the Obe or Obenet names. Some services may use other networks, private addresses, partner infrastructure or systems that do not appear in global BGP.

That boundary matters because Internet infrastructure profiles often jump from a matching ASN to claims about an entire business. The registry supports the statement that Obehosting AB is the named holder behind AS42675. It does not support assumptions about how much equipment the company owns, where it is installed, how many customers it serves or how the service behaves during failure.

Twenty prefixes create a larger monitoring surface

The current announced-prefix view for AS42675 contains 20 routes. Eleven are IPv4: 45.148.16.0/22, 193.182.111.0/24, 46.227.64.0/21, 193.187.88.0/22, 45.159.14.0/24, 185.157.160.0/23, 185.157.162.0/24, 217.64.150.0/24, 217.64.148.0/23, 45.15.16.0/24 and 185.157.163.0/24.

The nine IPv6 routes are 2a07:a880:4603::/48, 2a0e:1c80:1::/48, 2a0c:dd40::/29, 2a07:a880:4701::/48, 2a07:a880:4601::/48, 2a07:a880:4602::/48, 2a07:a880:4604::/48, 2a07:a880:3101::/48 and 2a0e:1c80:3::/48.

The routing-status endpoint summarizes the IPv4 set as 11 prefixes and 6,656 addresses. It expresses the IPv6 set as nine prefixes and 524,296 equivalent /48 units. That IPv6 figure is a normalization measure used to compare address space at a common prefix length. It is not a count of customers, hosts, active interfaces, sold subnets or usable services.

The variety of prefix sizes is operationally more informative than a single aggregate address total. There are larger IPv4 blocks such as a /21 and several /22s, alongside /23 and /24 routes. The IPv6 set combines a /29 with multiple /48s. Different route sizes may reflect allocation history, traffic engineering, customer separation, acquisitions, legacy networks or other arrangements. The public data does not explain which.

Twenty entries also mean twenty entities whose state can change. A prefix can appear or disappear, move to another origin, become more specific, lose visibility or change RPKI status. Monitoring the set as a whole can reveal change, but interpreting a change requires context from the operator. A withdrawn route could indicate maintenance, migration, a fault or the retirement of unused space.

The count should not become a proxy for business scale. A provider can announce many small routes while serving a limited set of systems. Another can aggregate a large operation into very few routes. Address space is coordination capacity, not proof of commercial capacity.

The defensible conclusion is that Obehosting has a materially larger public routing estate than a one-prefix edge network. That creates a useful accountability surface. It does not reveal what sits behind each route.

Dual-stack visibility is clear, end-to-end service is not

RIPEstat's routing-status view reports full sampled visibility for both protocol families. The IPv4 origins were seen by 330 of 330 sampled full-table RIS peers. The IPv6 origins were seen by 324 of 324. Within that measurement system and query time, the AS42675 origin set propagated throughout the available peer sample.

This is a strong control-plane observation. A prefix that appears across the complete sampled peer set is not merely present at one collector. It is broadly distributed through the BGP paths visible to the service. Repeated observations could identify a large visibility loss, a protocol-specific withdrawal or a shift in origin.

Full sampled visibility is not 100 per cent service availability. BGP collectors see route announcements. They do not test whether an application responds, a residential line carries traffic, a server has power, a customer circuit is provisioned or an operations team can recover a fault. A route can remain visible while equipment behind it fails.

The reverse is also true. A route can briefly disappear from some collectors without proving that every service is down. Traffic can move through another path or origin. Collector sessions can change. Operators may intentionally withdraw or aggregate a route. The routing state needs to be compared with service telemetry and change records.

Dual-stack propagation also does not prove protocol parity. The public record shows current IPv4 and IPv6 origins, but it does not show whether the same customers receive both protocols, whether the same equipment carries them, whether their paths are physically independent, or whether operational support is equal.

For a customer, the useful questions begin after the visibility check. Which prefixes belong to the purchased service? Which ASN originates them in normal operation? Are IPv4 and IPv6 carried through the same external handoff? What happens to each protocol during maintenance or upstream failure? Which measurements define availability?

The routing snapshot cannot answer those questions. It provides the baseline against which the answers can be tested. Obehosting's dual-stack identity is visible; the service architecture behind it remains private.

A valid ROA is specific evidence, not a company-wide badge

One route in the set received a more focused security-metadata check. RIPEstat maps 46.227.64.0/21 to AS42675 and marks it announced. The paired RPKI validation response is valid under Routinator. It contains a validating route origin authorisation with origin 42675, prefix 46.227.64.0/21 and maximum length 21.

That is concrete evidence that the sampled /21 and origin align with a published authorisation. A network applying route origin validation can use this information when deciding whether the announcement is consistent with the resource holder's authorization.

The result has precise limits. The maximum length of 21 means the tested authorization covers the /21 itself, not arbitrary more-specific routes. The response does not validate the other ten IPv4 routes or any of the nine IPv6 routes. Each prefix-origin pair requires its own current check.

RPKI also addresses one class of routing problem. A valid origin does not mean the path is optimal, the neighbour is trusted, the equipment is secure, the service is reachable or the company has resilient operations. It cannot prevent every route leak, policy mistake or malicious event. It supplies origin-authorisation metadata.

The correct operating statement is therefore narrow: at the observation time, the tested 46.227.64.0/21 origin had a valid matching ROA under the named validator. Turning that into "Obehosting's network is RPKI secure" would overstate the evidence.

A useful internal control would maintain expected RPKI state for every announced prefix, alert on invalid results and investigate unexpected unknown states. The public record does not show whether Obehosting operates such a control. It only gives outsiders enough data to perform their own periodic checks.

This distinction reflects a broader infrastructure principle. Security metadata matters when it is accurate, current and attached to the right number resource. Its value comes from a specific operational match, not from a badge applied to an organisation.

One observed neighbour raises a dependency question

The BGP-neighbours response for AS42675 contains one entry: AS3399 on the left side of the sampled paths. No additional neighbour appears in that endpoint's current response. The observation exposes a logical handoff in the paths available to RIPEstat.

The data does not label AS3399 as an upstream, peer, reseller, route server, customer or backup. It does not disclose a contract. Path position alone cannot establish who pays whom or which party controls the commercial relationship.

Nor does the one-neighbour response prove that Obehosting has only one external connection. Collector coverage is bounded. Private interconnections may not appear. Backup paths can remain unused. Multiple physical links can support one logical adjacency, while several BGP sessions can share one duct, building, power feed or provider network.

The observation is still useful because it defines an external question. If AS3399 is important to the public origin set, what happens when that adjacency is unavailable? Is another path configured? Is it tested? Does it share a failure domain? Which prefixes move, and how quickly?

Those questions require topology and incident evidence. A second ASN in a neighbour list would not by itself prove redundancy. Physical route, facility, power, carrier and operational control all matter. Redundancy exists only when the alternative can carry the intended service through the relevant failure.

For monitoring, changes in the observed neighbour set deserve review. A new neighbour can indicate migration, additional connectivity, traffic engineering or collector variation. The disappearance of AS3399 can be planned or disruptive. Neither should be interpreted without change records and service measurements.

The public fact is one observed logical adjacency. The dependency architecture behind it is unverified. That is a reason for precise due diligence, not a reason to declare the network fragile.

The Obenet service description provides context, not measurement

Obehosting's public site uses the Obenet name. Its page title describes a simple and powerful broadband proposition. The metadata says the service is intended for private individuals and companies and refers to a backbone. It names broadband, Internet, Wi-Fi, television, telephony, enterprise service, municipal networks and fibre.

These descriptions explain why AS42675 matters beyond an abstract routing registry. A broadband or hosting operation needs public identifiers, reachable contacts, route policy and interconnection. The ASN can support services, management systems, hosted endpoints or customer address space.

The website remains a first-party commercial source. Terms such as fast, reliable or powerful are claims, not measurements. The accepted public record does not provide throughput tests, availability data, customer counts, installed capacity, fibre route maps, facility inventories or incident histories.

The word backbone is especially easy to overread. It can describe a substantial owned transport network, capacity leased from other carriers, a combination of metro and long-haul systems, or simply the core network supporting a service. Without topology, ownership and operational records, the term does not establish physical scale.

Municipal-network and fibre references likewise do not identify who owns the fibre, who operates each access network, where handoffs occur or what restoration obligations apply. Swedish broadband services often involve several layers of network owner, communications operator, service provider and customer relationship. The captured page does not map Obehosting's role in each case.

The route estate can corroborate that Obehosting has a real operating network identity. It cannot validate the quality adjectives or reveal the physical delivery chain. Readers should therefore keep the commercial proposition and the observable control plane in separate columns.

The useful synthesis is modest. Obehosting presents broadband and network services under the Obenet brand. AS42675, its prefixes and contact data provide a real public coordination surface. The service outcome still requires independent operational evidence.

Prefixes are not facilities

An IP prefix is a block of addresses that can be announced through BGP. It is not a building, rack, fibre pair, access node or power feed. This distinction becomes important when a provider's public route estate is used to infer physical infrastructure.

The 20 AS42675 prefixes could support systems in one facility or many. They could be divided among internal functions, customers, locations or historical networks. Some addresses may be active, reserved or unused. The routing data does not disclose utilization.

Likewise, a Swedish registry address is not a data-centre location. Massvägen 4 is part of the organisation's public contact record. The source does not establish that equipment is installed there, that the address is a network point of presence, or that it is where services are operated.

Facility claims require different evidence: property and planning records, operator documentation, power arrangements, cross-connect data, technical certifications, site photographs, independent maps or customer confirmations. None can be inferred from the ASN alone.

The same applies to fibre. Prefix reachability does not show the cable route, whether fibre is owned or leased, whether two circuits share a trench, or where responsibility changes between networks. A logical dual-stack service can depend on one physical corridor.

Keeping these concepts separate prevents a common form of infrastructure inflation. A visible network can be described as a real network without turning its address space into a fictional asset map.

For Obehosting, the physical boundary remains a question for future evidence. The current record is strong on number resources and BGP state. It is silent on facility count, route geography, power, cooling, installed equipment and usable capacity.

That silence should remain explicit. It protects the accuracy of the profile and gives counterparties a clear list of documents to request.

Capacity requires a defined unit and operating state

No accepted public source provides a usable-capacity figure for Obehosting's services. The 6,656 IPv4 addresses and IPv6 /48 normalization are not bandwidth. Prefix length does not translate into gigabits per second, rack capacity, subscriber lines or traffic volume.

A meaningful capacity statement must specify what is being measured. For a fibre link it might be lit optical capacity, provisioned wavelength capacity or contracted throughput. For broadband it might be access-line speed, contention, backhaul capacity or measured peak delivery. For hosting it might involve powered rack space, network commit, storage or compute.

The operating state matters as much as the number. Designed capacity can exceed installed capacity. Installed equipment can remain unpowered. Lit capacity can exceed sold capacity. Sold capacity can exceed usable capacity under congestion or failure. None of these states should be collapsed into one headline figure.

The Obe site metadata uses speed-oriented language, but it does not supply a measured methodology or time series in the captured page. No independent test in the current evidence set establishes performance. That prevents a capacity or quality claim.

The BGP view can contribute to capacity analysis only indirectly. It shows that the prefixes are announced and visible. It does not show how much traffic they carry, which paths carry it or how much headroom exists.

A customer evaluating Obehosting should therefore ask for service-specific measures: committed rate, burst conditions, contention policy, observed utilization, maintenance headroom and failure-mode capacity. The answer should identify the measurement point and period.

Without those details, the honest description is operationally limited. Obehosting has a broadly visible dual-stack route estate. The public record does not quantify how much service that estate can deliver.

Resilience must follow the failure path

Broad route visibility can coexist with a single physical dependency. A prefix may be visible through hundreds of collectors while the service behind it relies on one power feed, one facility, one fibre corridor or one operational team.

The AS42675 snapshot does not reveal independent failure domains. One observed neighbour cannot prove or disprove them. The presence of IPv4 and IPv6 does not create physical redundancy; both protocols may traverse the same equipment and path.

To establish resilience, a provider needs to identify the failure being tested. A carrier outage, fibre cut, router failure, facility power loss, software fault and control-plane error require different alternatives. A design that handles one may not handle another.

The alternative path also has to be usable. It must have enough capacity, current configuration, reachable staff and tested procedures. An untested backup or an alternate route sharing the same trench is not equivalent to proven recovery.

Public routing changes can help document a failure exercise. If traffic is intended to move to another neighbour or origin, BGP observations can show whether the control-plane change occurred. They still cannot prove that customer applications worked or that the physical path was independent.

For Obehosting, the current public baseline makes a future exercise measurable. Operators can record the expected 20 prefixes, origin ASN, neighbour state and RPKI policy before and after a test. Customers can compare those signals with service availability.

Until such evidence is available, resilience claims remain outside the verified boundary. This is not an accusation. It is the standard implied by infrastructure dependence: redundancy is real only when the failure path and recovery are documented.

Abuse and incident contacts are part of infrastructure

RDAP lists Obenet NOC as the administrative, technical and abuse contact for AS42675. The abuse mailbox is [email protected]. A public contact route is operational infrastructure in its own right because other networks need a way to report abuse, misrouting and security incidents.

The presence of the mailbox is a useful coordination fact. It does not prove delivery, response time, escalation ownership or round-the-clock coverage. The current evidence does not test whether messages are acknowledged or how incidents are triaged.

Different events require different owners. An abuse complaint may involve a customer system. A route leak needs a network operator. A facility outage needs site and power teams. A customer-impact incident needs service operations and communications. One mailbox can receive reports without controlling every response.

The public organisation and contact data should therefore be maintained together but not treated as identical. The legal company is responsible for contracts and corporate obligations. The network contact handles resource and routing matters. The service team restores customer outcomes.

Record accuracy affects recovery. An outdated contact can lengthen an incident even when the network design is sound. A current route origin with an unreachable NOC creates a coordination gap. Conversely, effective incident handling can mitigate faults that public routing data alone cannot prevent.

A due-diligence review can test the chain without exposing sensitive detail. It can confirm that the mailbox is monitored, that routing escalations reach an authorised engineer, that customers have a separate support path and that external contacts are updated after organisational change.

AS42675 gives the review a precise reference. Reports can cite the ASN and affected prefix rather than relying on a brand name. That is a practical benefit of accurate registry data.

The legal and operational roles should not be merged

The registry's company name, member listing, NOC contact and public brand align sufficiently to identify Obehosting AB. They still describe different roles.

Obehosting AB is the named organisation. Obenet is the public-facing service name on the captured site. Obenet NOC is the technical and abuse contact in RDAP. The network identifier is AS42675. Keeping these roles explicit helps avoid ambiguity during contracts, changes and incidents.

The address in the registry is also role-specific. It supports contact and identity. It does not prove where servers, routers or staff are physically located. A corporate or postal address can be separate from operational sites.

This matters when a directory profile is used for procurement. A customer should know which legal entity signs the agreement, which brand supplies the service, which team operates the network and which party owns or leases each critical asset.

The public record answers the first layer well enough to proceed. It does not answer the asset and contract layers. Those should be verified with current service documentation rather than filled by assumption.

Changes in any layer deserve a recorded update. A brand can change while the legal entity remains. A network can move to another ASN. A NOC can change address or mailbox. A merger can alter resource control. Historical continuity should not be inferred from a familiar name.

The benefit of the current exact binding is that future changes have a baseline. The entity ID, organisation handle, ASN and route set can be checked separately. That makes change visible without claiming that the current arrangement is permanent.

What an expected-state record can monitor

AS42675 has enough public structure for a compact expected-state record. The record can list the holder, organisation handle, 20 current prefixes, protocol-family counts, sampled visibility, observed neighbour, tested RPKI result and contact details.

The first class of alert is an identity change. A different holder, organisation handle or company status requires review. It may be routine administration, restructuring or a deeper control change.

The second is a route-set change. A new prefix, withdrawal, more-specific route or origin change can reflect planned engineering, acquisition, delegation or an incident. The alert should identify the exact prefix and time.

The third is a visibility change. A large drop among RIS peers can signal propagation trouble, but it can also reflect collector variation. Service measurements and operator notices are needed before assigning customer impact.

The fourth is a security-metadata change. A valid sampled RPKI result becoming unknown or invalid deserves investigation. The same is true when a previously unknown prefix becomes valid. The expected state should cover each route separately rather than assuming the sample represents the set.

The fifth is a neighbour change. A new or disappearing adjacency is an observable event, not a verdict. It should be compared with planned changes and service behaviour.

These fields support incident triage without exposing private topology. They answer whether the public coordination surface changed. They do not answer whether a customer application worked, so the monitoring record must link to service telemetry.

The approach is deliberately factual. It avoids a synthetic network score and preserves the evidence needed for human interpretation.

Procurement can turn public facts into bounded questions

A customer buying broadband, hosting or network service from Obehosting can begin with the exact public identity. Does the purchased service use AS42675? Which of the 20 prefixes apply? Which route origin and RPKI state should the customer expect?

If the service does not use AS42675, the provider can identify the relevant network and explain the relationship. That answer is more useful than assuming the most visible ASN represents every product.

The customer can then ask about external dependencies. Is AS3399 part of the normal path? Are other external connections available? Are they logically and physically independent? How are they tested?

Capacity questions should remain service-specific. What rate is committed, where is it measured and what remains available after a component failure? Prefix count and full BGP visibility cannot substitute for this information.

Facility and access questions follow. Which party owns the access network, fibre, routers and hosting location? Which party supplies power? Where do responsibilities change? What recovery times apply to each layer?

Security questions can use the sampled valid ROA as a starting point. Does every production prefix have an expected authorization? Who approves changes? What alerts identify invalid or unexpected origins?

Finally, incident ownership should be explicit. The public abuse contact is useful, but a customer needs a support and escalation path tied to the contract. The provider can show how an external routing issue, access fault and hosted-service incident reach the right teams.

None of these questions assumes a deficiency. They convert a visible public control plane into a disciplined verification plan. Strong private evidence can answer them even when it is not published.

What would materially strengthen the public assessment

The first improvement would be route-by-route RPKI evidence. The current valid result covers one /21. A current table for all 20 prefixes would show which origins are valid, unknown or invalid and would prevent one sample from being overgeneralized.

The second would be a bounded topology statement. It need not publish sensitive maps. It could identify whether AS42675 is used for broadband, hosting, management or several roles, and whether major services rely on another ASN.

The third would concern external handoffs. A statement of logical and physical diversity, supported by test or incident evidence, would answer questions raised by the one observed neighbour. A list of provider names alone would not be enough.

The fourth would separate installed and usable capacity. Service-specific metrics, measurement points, utilization ranges and failure-mode headroom would make capacity claims meaningful without disclosing customer data.

The fifth would connect company, brand and NOC responsibilities. An up-to-date incident matrix could show who controls routing, abuse response, access restoration, facilities and customer communication.

Independent measurements would add another layer. Route monitoring, latency observations, outage records and recovery exercises could test whether the public control plane and service outcomes move together.

Every addition should retain a date and scope. Infrastructure changes. A strong assessment does not freeze one architecture forever; it records what was true, what was measured and what remains unverified.

Running routes reveal coordination, not the whole system

The registry serves as a ledger for unique Internet number resources. It connects AS42675 to Obehosting AB and supplies public contacts. RIPEstat observes the routes that the distributed BGP system carries. The member directory identifies an institutional relationship. The Obe website describes a commercial proposition.

Each source answers a different question. None should dominate the others. The company website cannot certify route state. The registry cannot certify service quality. BGP cannot certify legal ownership or physical diversity. A member listing cannot certify customer outcomes.

Their agreement is still meaningful. The exact company, ASN holder and public brand align. Twenty routes are active. Both protocol families are broadly visible in the sample. One tested IPv4 prefix has valid origin-authorisation metadata.

The gaps are just as clear. The public record does not show which services use which prefixes, where equipment is installed, who owns the underlying fibre or hosting facilities, how much capacity is usable or how recovery works.

This balance is the reality layer. Obehosting has a real, auditable dual-stack network identity. The identity is not a substitute for the delivery chain.

The right conclusion is neither promotional nor dismissive. AS42675 gives customers, peers and researchers a precise public surface to monitor. Operational assurance must come from service mapping, independent measurements, tested failure paths and current ownership records.

That is what must continue working for dependent organisations: not merely the announcement of 20 prefixes, but the chain of resources, people, facilities, contracts and recovery controls behind them. The public Internet shows the first part of that chain. Obehosting must supply evidence for the rest where customers and counterparties depend on it.

Route history should preserve changes without inventing causes

The current origin set is a point in time, not a permanent inventory. RIPEstat's routing-status response identifies an earlier first-seen observation for AS42675 in April 2007 and a current last-seen observation for 185.157.163.0/24 on 29 July 2026. The dates show that the ASN has a longer observable routing history than the registration event in the filtered RDAP response might suggest.

The difference does not imply an error. Registry entities can be recreated, transferred, migrated or represented differently across services. Historical BGP observation and current RDAP event history answer different questions. The first records when a collector saw a route under the origin. The second records events attached to the present registry representation.

An accurate monitoring record should preserve both without forcing a single narrative. It can state that AS42675 appeared in the routing data in 2007, while the captured RDAP entity reports a 2018 registration event and a 2021 last-change event. Explaining why those dates differ would require historical registry and organisational evidence not present here.

The same discipline applies to prefixes. Today's 20-prefix set may include blocks added at different times or acquired under different arrangements. A route that disappears next month should remain in history with its last observation. A new route should receive a first observation and an origin check. Neither event automatically means expansion or contraction of customer service.

Historical records become particularly useful during incidents and migrations. If a familiar prefix moves to another origin, operators can compare the change with authorization and maintenance records. If an old prefix returns, they can determine whether the return was planned. If visibility shifts only for IPv6, they can separate a protocol-specific event from a complete outage.

Causes should be added only when supported. BGP itself does not say that a change resulted from a fibre cut, router replacement, commercial dispute, acquisition or configuration error. A status page, incident report, change ticket or independently verified operator statement is needed for that step.

This restraint keeps the route history useful. A chronology of observed state can be audited and compared. A chronology filled with guessed causes becomes unreliable precisely when it is needed during a real failure.

Customer impact begins beyond the BGP announcement

A public route is one dependency in a longer service chain. For an Obehosting customer, the chain may begin with an access circuit, municipal network, hosted system or enterprise connection. It may then cross equipment controlled by another operator before reaching AS42675 and an external handoff. The exact path is not disclosed in the current public material.

When BGP changes, customer impact depends on where the change occurs and what alternatives remain. A full withdrawal of a service prefix can make public endpoints unreachable. A partial visibility loss can affect some networks while others continue to connect. A neighbour change may be invisible to users if traffic moves normally. An application can fail with no routing change at all.

This is why outage attribution needs more than a route graph. Investigators should combine the expected prefix and origin with active reachability tests, DNS state, application checks, access-network alarms, facility power status and customer reports. The evidence should identify the first failed layer rather than assuming that the most visible layer caused the event.

The response sequence also matters. If AS42675 loses a route, the network team may restore origin or adjacency state. If the route remains visible but an access node is down, a field or partner team may own recovery. If a hosted system has power but fails application checks, the responsible service team changes again.

A mature incident record would preserve timestamps for detection, escalation, route changes, service restoration and customer confirmation. It would name the organisation controlling each step. The public abuse mailbox can start coordination, but the accepted sources do not show the complete escalation chain.

Customers need the effect of the failure in service terms. Which circuits, hosted systems, regions or functions were affected? Was the service unavailable, degraded or rerouted? Did the alternative retain the contracted capacity? How long did recovery take, and which dependency delayed it?

Those questions connect control-plane monitoring to infrastructure accountability. Without them, a BGP event remains technically interesting but commercially incomplete. With them, the route baseline can shorten diagnosis and verify whether recovery followed the documented design.

The current public evidence cannot supply an Obehosting outage history or customer-impact map. It can establish the identifiers that an incident record should use. AS42675 and its 20-prefix set give operators and counterparties a common reference while the service-specific evidence supplies the consequence.

Operational continuity depends on record accuracy and tested handoffs

Number-resource records are sometimes treated as administrative overhead. In practice, they are part of continuity. A correct ASN holder, current abuse contact, accurate route origin and valid authorization can reduce uncertainty when another network sees suspicious or broken routing.

Accuracy alone is not sufficient. The people named by the record must be reachable, authorised and connected to the systems that require change. A perfectly formatted mailbox that does not reach an operator is weak infrastructure. A skilled operator without current public contact data can be difficult for peers to find.

Handoffs deserve the same attention. The observed AS3399 adjacency is a coordination boundary between autonomous systems. The service boundary between Obehosting and an access-network owner, facility operator or customer is another. Each boundary needs a clear owner, expected state and escalation path.

Testing makes those records operational. A routing exercise can confirm that an alternate origin or adjacency behaves as designed. A contact exercise can confirm that reports reach the right team. A service exercise can test whether customers retain reachability and usable capacity when a component is removed.

The tests should match the claim. A successful BGP failover does not prove facility power resilience. A generator test does not prove upstream diversity. A customer-service drill does not prove route authorization. Combining results is legitimate only when the dependencies and interfaces are documented.

For Obehosting, the public baseline is detailed enough to support these tests without revealing sensitive topology. Expected prefixes, ASN, sampled visibility, one current neighbour and a tested RPKI state can all be written into runbooks. Private service maps can connect them to equipment and contracts.

What remains unknown should stay visible in the record. The current evidence does not identify physical sites, access routes, usable capacity, alternate carriers or recovery results. Those are not optional details when resilience is claimed; they are the proof.

The wider lesson is practical. Running Internet infrastructure depends on unique identifiers, accurate records, reachable operators and handoffs that continue to work under stress. AS42675 demonstrates the visible coordination layer. Operational continuity depends on whether the hidden layers have been mapped and tested with equal care.

Sources