KAVKAZNET Kavkaz Internet Service Ltd. makes a local connectivity bill depend on upstream routes and field repair

Summary

• KAVKAZNET is publicly visible through two different kinds of evidence: the company-run CISMAN site, which gives a Mineralnye Vody address, customer phones, tariffs, connection steps and support channels, and internet routing records for AS50712, where RIPEstat lists KAVKAZNET Kavkaz Internet Service Ltd. as the holder.
• The public network footprint is real but narrow. RIPEstat shows three announced IPv4 prefixes, 91.210.96.0/22, 195.211.244.0/22, and 176.124.226.0/23, totaling 2,560 IPv4 addresses, and the same status view shows no visible IPv6 announcement.
• The operating thesis should be downgraded from "documented regional infrastructure platform" to "observable local access ISP with externally routed IPv4 service." The company site supports access, fibre construction, telephony and digital television offers, but public records do not prove ring topology, tower independence, backup power, spares, physical route separation or field-crew capacity.
• The practical risk is local, not abstract. A subscriber's bill depends on two layers at once: whether the local drop, pole, building cable, router and field appointment can be kept working, and whether AS50712's upstream routes remain visible through the providers and peers that carry those prefixes to the wider internet.

KAVKAZNET is a useful case because it sits at the scale where internet resilience becomes easy to overstate. Large national carriers publish investor decks, outage notes, cloud interconnect brochures and regulator filings. Very small neighbourhood networks may leave only a phone number, a tariff image and a few addresses in routing databases. KAVKAZNET falls in the middle. The company has an official web presence at cisman.ru, a customer-facing brand in Russian, and a routed autonomous system that has been visible for years. Yet the public record stops before the most important operational questions: where the access plant runs, how many upstream paths are physically independent, what happens when local power fails, how quickly field crews can replace a bad customer drop, and whether the newer prefix capacity corresponds to better customer service or only to address management.

The right way to read KAVKAZNET is therefore neither dismissive nor promotional. The public evidence is enough to say the company is not just a dormant corporate shell. Its home page describes Kavkaz Internet Service as an older telecommunications operator in the Caucasian Mineral Waters market, founded in 2003, offering internet access to individuals and legal entities, fibre-network laying, telephony and digital television. Its contacts page lists customer service and technical support numbers, a sales email, tax identifiers and a Mineralnye Vody legal and factual address at Karl Marx 68a. Its connection page describes an ordinary local-access installation sequence: choose a tariff, confirm feasibility by phone, sign a contract in the office, agree an appointment, and wait for a specialist to bring cable from the company's equipment to the customer's computer and configure the service. Its support page gives support phone numbers and embeds a SmartNut ticket form. These are the traces of a real retail or small-business connectivity operation.

The same evidence also sets a ceiling. A tariff page, a support phone and a cable-installation promise do not reveal how many access nodes the company operates, whether a street cabinet has battery backup, whether aerial drops share utility poles with power lines, whether multiple upstreams reach the network over separate ducts, or whether the same contractor must repair both last-mile faults and backbone faults. The company says it lays fibre networks, but the public site does not publish a route map, an engineering standard, a customer density map, a list of towns covered, an SLA, a maintenance window policy or an outage archive. That is why this profile treats the company as a local access provider with a verifiable routed footprint, while keeping any broader "regional infrastructure" language conditional.

The routing layer is the firmer half of the record. RIPEstat's AS overview for AS50712 names the holder as KAVKAZNET Kavkaz Internet Service Ltd. and shows the AS as announced at the July 10, 2026 query time. RIPE's database aut-num record gives the as-name KAVKAZNET, status ASSIGNED, organization ORG-KISL2-RIPE, and policy lines that accept routes from AS3216, AS8563 and AS12494 while announcing AS50712 to AS3216, AS8563 and AS12494. The RIPE organization record identifies Kavkaz Internet Service Ltd., country RU, registration number 1032699742448, and an address at 50 let Oktiabria 48a in Mineralnye Vody. That address differs from the company site's Karl Marx 68a address, which is not unusual for old registry data but matters for due diligence: a public routing database address should not be treated as the physical location of a point of presence.

The announced prefix set is small and coherent. RIPEstat's announced-prefixes view lists 91.210.96.0/22, 195.211.244.0/22, and 176.124.226.0/23 as originated by AS50712. A /22 contains 1,024 IPv4 addresses and a /23 contains 512, so the visible address pool is 2,560 IPv4 addresses before customer allocation, network infrastructure, reserved addresses and any private addressing are considered. That is consistent with a local or small regional access provider, not with a national-scale carrier. The routing-status feed reports three IPv4 prefixes, 2,560 IPv4 addresses, no IPv6 /48s, IPv4 visibility from all 327 listed RIS peers, and no IPv6 visibility among 321 listed IPv6 RIS peers at the same timestamp.

That absence of visible IPv6 is not a moral judgement. Many local access networks still run customer services over IPv4, often with private addressing, carrier-grade NAT, or legacy public assignments. But it is a resilience and modernization clue. IPv6 can reduce pressure on address translation layers and make customer troubleshooting cleaner; its absence in public BGP means that a large part of the customer experience may still depend on IPv4 address management and NAT state inside the operator's network. When a local ISP has only three visible IPv4 routes and no visible IPv6, the operational question becomes less "how many addresses exist" and more "which devices and which staff keep those addresses usable during a fault?"

The newest route object adds another clue. RIPE's route record for 195.211.244.0/22 was created in 2010, and the route record for 91.210.96.0/22 was created in 2012. The 176.124.226.0/23 route record, by contrast, was created on June 7, 2026. RIPEstat's routing history shows the 176.124.226.0/23 prefix appearing in June and becoming broadly visible afterward. A new route can mean many things: address expansion, a shift from another origin, a customer addressing change, upstream policy cleanup, or preparation for future demand. The public evidence does not say which. What it does say is that the operator's routed perimeter was not static in mid-2026, so anyone assessing continuity should ask whether internal addressing, customer CPE configuration and support scripts were updated around the same time.

The upstream picture is promising but still not enough to prove physical diversity. RIPE's aut-num record lists AS3216, AS8563 and AS12494 in its policy, while RIPEstat's routing-consistency view shows AS3216 and AS12494 present both in the RIPE policy and in BGP, AS8563 present in the policy but not seen in BGP, and a set of additional observed neighbours not declared in the policy. RIPEstat's neighbour view counted 17 unique neighbours on July 10, 2026, including left-side observations for AS3216, AS12494, AS6939 and AS20764, plus several uncertain observations. BGP.tools similarly presents AS50712 as an active eyeball network with three IPv4 prefixes and zero IPv6 prefixes, and it identifies AS3216 Vimpelcom PJSC and AS12494 OOO Post Ltd as upstreams at page-load time.

For a local access ISP, that mix of route records is useful but not conclusive. Multiple upstream ASNs can mean real internet-path diversity, but the public record does not show whether those services enter Mineralnye Vody through separate fibre routes, separate buildings, separate power feeds, separate optical transport systems or separate commercial resellers. If two upstream contracts ultimately depend on the same metro fibre corridor or the same powered facility, a backhoe cut or power incident can defeat the apparent diversity. Conversely, even a small AS can be more resilient than it looks if the operator has physically separated handoffs and competent traffic engineering. Public BGP can show that prefixes are globally reachable. It cannot by itself show whether a technician has to drive to one cabinet with one spare SFP before the town comes back online.

That is why the customer-facing installation language matters. The connection page does not describe a fully remote, self-provisioned service. It describes office confirmation, contract signing, an agreed visit and a specialist running cable from company equipment to the customer's computer. It also states a connection term of one to three weeks from application. This is ordinary for a local wired access business, and it tells us where the bottleneck may be. A new customer is not merely buying a BGP route. The customer is buying survey capacity, office coordination, a drop cable, a home or office visit, configuration work, and, if the customer wants it, a WiFi router installation. If those processes are thinly staffed, growth can show up as delayed installs long before BGP visibility changes.

The same labour dependency appears in fault recovery. If a customer loses service because a router fails, a cable is damaged inside a building, a pole span is cut, an access switch loses power, or a connector is water-damaged, upstream routing will still look healthy from global vantage points. The prefix will remain announced. RIPE RIS peers will keep seeing AS50712. IPinfo may still list the ASN as an ISP with 2,560 IPv4 addresses and no IPv6 addresses. Yet the affected subscriber will experience the network as down. That is the gap between internet-reachable infrastructure and usable local service. KAVKAZNET's public support numbers and ticket form show a path to report faults, but they do not show mean time to repair, after-hours staffing, spares stock, escalation rules, maintenance windows, battery runtime or whether the company has separate crews for backbone and customer drops.

The most concrete operating surface is the Mineralnye Vody office. The contacts page lists the legal and factual address as Karl Marx 68a and gives INN 2630032936 and OGRN 1032699742448. The personal-data policy repeats the operator identity with INN 2630032936 and the Karl Marx address. The site map confirms the small set of public pages: home, tariffs, connection, support, guestbook, licences, personal-data policy and contacts. This is not a rich corporate disclosure environment, but it is enough to anchor the service to a place. The office is where a customer is told to sign a contract and where a prospective subscriber is told to verify the possibility of connection. In a larger market, digital onboarding can hide the local labour chain. Here, the public process exposes it.

The tariffs and licence pages also support the access-provider reading, while leaving the same gaps. The tariff page says its tariff groups are meant for citizen subscribers using communications services for personal, family and domestic needs, not for business activity. It links to a downloadable tariff document at tariff_20251209174220197.jpg.doc, and it tells customers to go to the office or use the online application form after choosing a plan. The licence page says the company's activity is licensed and displays a licence image at license_img/20150312163755232.jpg. Those are useful facts for identifying a retail telecom business, but they do not tell us service availability by building, traffic contention ratios, upstream commit size, access technology split, or the difference between advertised and actually usable capacity during peak evening demand.

That difference between installed and usable capacity is one of the central questions for a regional ISP. A company can have enough global address space, a credible upstream, and a local fibre claim, yet still deliver uneven experience if the access layer is oversubscribed or if backhaul from a neighbourhood aggregation point is thin. Public BGP sees the origin, not the customer. It does not show whether a 100 Mbps tariff is backhauled by a 1 Gbps, 10 Gbps or smaller uplink at the aggregation site. It does not show whether customer traffic is balanced across upstreams or pinned to one path. It does not show whether residential video peaks collide with business traffic. KAVKAZNET's public record gives the right evidence to say "there is a routed ISP here," but not enough to say "the access network has proven headroom."

The provider's own language about fibre construction should also be read carefully. On the home page, the company presents fibre-network laying as one of its activities. Fibre is a strong word in local marketing because it suggests modernity, capacity and reliability. Yet fibre in the ground is only one part of resilience. A passive fibre span can still fail if it shares a duct with other utilities, if there is no diverse route, if the termination point loses power, or if the same crew must repair both customer drops and backbone sections. Fibre to a building and fibre to a cabinet carry different operational implications. The public site does not separate those cases. The proper conclusion is that fibre activity is part of the company's offer, not that every customer is protected by a physically diverse fibre architecture.

The routing history around July 2 and July 3, 2026 illustrates why careful interpretation matters. RIPEstat's routing-history data for June 1 through July 10 shows periods where the three originated prefixes had lower full-peer visibility than the surrounding days, followed by recovery to broad visibility. That does not automatically mean a KAVKAZNET outage. RIS visibility can shift because of route collector peers, upstream policy, measurement artifacts or transient internet events outside the operator's direct control. But it is still a useful diligence signal: when visibility changes, the right follow-up is to compare BGP data with customer reports, trouble tickets, maintenance notices and upstream incident notices. The public web record available here does not provide that corroborating operational diary.

Another subtle sign is the lack of a public PeeringDB profile. A query for net records with ASN 50712 returned no PeeringDB data during this review. That does not prove the company lacks peering or formal interconnection; PeeringDB is voluntary, and many small access providers do not maintain a profile. It does mean that buyers and partners cannot easily see declared traffic ratios, interconnection locations, peering policy, NOC contact details or exchange presence from that source. In a larger regional-ISP evaluation, that missing self-declared interconnection layer would lower confidence. For a local retail access provider, it simply pushes more of the diligence burden onto direct questions.

RPKI is another confidence marker with limits. RIPEstat's validation checks for 91.210.96.0/22, 195.211.244.0/22, and 176.124.226.0/23 returned unknown status with no validating ROAs in the checked responses. Unknown is not invalid. It does not say the routes are hijacked or misoriginated. It says the public validation layer did not provide cryptographic confirmation for those origin pairs at query time. For a small ISP, creating and maintaining ROAs is a manageable governance task that can reduce exposure to route leaks and filtering surprises. For a customer, it is not the first thing that will decide whether home internet works tonight, but it is part of the upstream hygiene picture.

The service-area question remains the largest evidence gap. The company site repeatedly anchors itself in Mineralnye Vody and the Caucasian Mineral Waters region, but it does not publish a coverage map or a settlement list in the pages reviewed. A "regional ISP" category can be appropriate in the broad taxonomy sense because the company is a local access operator rather than a national backbone carrier, but the public evidence does not support a precise region-wide footprint. A cautious metadata reading is therefore: Russian local access ISP, Mineralnye Vody base, KMW-region claim from the company site, current AS50712 routing footprint, and unproven physical coverage beyond what a prospective customer can verify by calling the office. That is a downgrade from a fully documented regional network.

This matters for the people behind the bill. Residential customers care about whether video calls work in the evening, whether online school stays connected, whether a payment app loads, and how long a repair takes when a cable is damaged. Small businesses care about card terminals, booking systems, accounting systems and cloud software. Municipal or institutional buyers care about service continuity during storms, power disturbances and local construction work. KAVKAZNET's public evidence shows the company has the channels to sell and support those customers. It does not show the resilience commitments that would let a buyer price the consequences of a multi-hour or multi-day incident.

The main failure paths are therefore concrete. First, an access cut can isolate customers even when AS50712 remains globally visible. The company connection process suggests cable runs from company equipment to the customer, so building-level wiring, aerial drops, shared conduits and customer-premises equipment are all potential weak points. Second, a power outage at an access node can convert a fibre or Ethernet service into a dark local segment unless there is tested battery or generator backup. Third, an upstream loss can reduce reachability if the remaining routes do not carry all traffic well or if apparent upstream diversity shares a physical path. Fourth, a field-repair shortage can stretch a local problem from hours to days, especially if installation work and fault response draw on the same people. Fifth, congestion can degrade service without producing a clean outage visible in BGP.

None of those failure paths is unique to KAVKAZNET. They are the economics of small access networks. Local ISPs often win customers through proximity, lower overhead, flexible installation and knowledge of buildings or streets that national carriers treat as marginal. Those advantages are real. The tradeoff is that resilience depends on operational details that are easy to hide from the public web: spare ONTs or routers, switch inventory, emergency fibre repair agreements, pole access rights, after-hours call rotation, backup-power maintenance and a disciplined upstream plan. A local operator can be excellent at these details without advertising them. A local operator can also be fragile while looking fine in BGP. Public records cannot decide which one is true.

For KAVKAZNET, the most defensible positive conclusion is that the routed edge appears current and the customer-facing site appears coherent. AS50712 is not merely an old registry object with no announcements. It is visible through RIPEstat, corroborated by third-party pages such as BGP.tools and IPinfo, and tied to company identity records that align with the CISMAN site. The official pages show service offerings, connection steps, support numbers and a licence page. That combination is stronger than a single whois record. It supports active local ISP status.

The most defensible negative conclusion is that no public source found here proves operational resilience. There is no public topology diagram. There is no published route-diversity statement. There is no backup-power standard. There is no outage archive. There is no list of upstream physical entry points. There is no published SLA. There is no published field-crew coverage table. There is no customer-facing explanation of whether services are delivered by fibre to the premises, fibre to the building, Ethernet over local plant, fixed wireless, or a mix by address. There is no visible IPv6. There are no validating ROAs in the RIPEstat checks reviewed. These are not reasons to say the network is failing; they are reasons to keep the evidence grade below strong.

A buyer or public-sector counterparty should ask KAVKAZNET six direct questions before treating the service as critical infrastructure. Which addresses can the company actually serve today, and by which access technology? Which upstream providers carry customer traffic now, not only in old policy records? Are those upstream handoffs physically separated and powered independently? Which access nodes have battery backup, for how long, and when was the last load test? What is the repair process for a cut cable, a failed access switch, a failed CPE device and a lost upstream? How many technicians can respond during a regional weather or construction incident, and what spares are stocked locally? These questions are not adversarial. They are the ordinary translation of public routing facts into operational risk.

The questions also show why the company's local scale is not automatically a weakness. A Mineralnye Vody access provider can sometimes know its buildings, landlords, pole routes and repeat fault locations better than a national carrier working through a distant contractor queue. The same office that slows digital onboarding can speed a practical repair if a manager knows which building entrance is locked, which roof needs permission, or which street excavation cut the same cable last year. That is the local-ISP bargain: proximity can replace some of the scale advantages of a large carrier. But proximity only becomes resilience when it is organized. The public pages show an office and support channels; they do not show the operating discipline behind them.

For a household, this distinction may look small until the first outage. A residential customer who can call the office and reach a local technician may prefer KAVKAZNET even if a large carrier has more national backbone capacity. A small retailer may care more about a field visit within a day than about abstract upstream diversity. A school or clinic, however, cannot assume that helpful local staff equal redundant infrastructure. If one access cabinet, one power feed or one upstream handoff sits behind many customers, local responsiveness may shorten the outage but cannot eliminate the shared point of failure. The company's connection page makes the service personal and physical. That is a strength for customer relationship and a reminder that the repair surface is also personal and physical.

The three-prefix footprint should be interpreted with the same restraint. A total of 2,560 public IPv4 addresses can support far more than 2,560 customers if an operator uses private addressing, NAT, dynamic assignment or pools for infrastructure and business customers. It can also support fewer visible end users if many addresses are tied to routers, servers, management systems, business circuits or idle inventory. The number is useful as a scale indicator, not a customer count. It says KAVKAZNET is not operating at the address scale of a national carrier. It does not say whether the evening peak is overloaded, whether business circuits receive dedicated addressing, or whether residential customers sit behind a shared translation layer. Those details determine user experience much more directly than the total count in public BGP.

The IPv4-only public posture raises a second practical issue: troubleshooting clarity. When a small access network uses IPv4 with NAT, a customer complaint can involve several layers at once: the home router, the customer's private address, a shared public address, the operator's NAT state, DNS behaviour, the upstream route and the remote service being reached. None of that is inherently bad. It is how many access networks work. But it increases the importance of support tooling and staff knowledge. If support staff can map a customer session to the right aggregation device and address pool quickly, IPv4 scarcity is manageable. If records are manual or fragmented, even a simple complaint can become a long back-and-forth. Public records do not show which side of that divide KAVKAZNET is on.

The newer 176.124.226.0/23 route is therefore a diligence trigger. If it was added to relieve address pressure, customers should eventually see fewer NAT or assignment constraints. If it was added for infrastructure, business services or route-policy cleanup, the retail impact may be minimal. If it reflects a migration, support staff need accurate customer-facing scripts and CPE settings. The public route object's June 2026 creation date and RIPEstat's June visibility are enough to ask the question, not enough to answer it. A company response such as "this prefix is for residential expansion in these areas" would support a stronger operating story. A response such as "this is administrative address housekeeping" would still be legitimate but would not change the resilience grade.

There is also a subtle distinction between upstream reachability and upstream recoverability. RIPEstat and BGP.tools can show that other networks see AS50712 through particular paths. They cannot show the commercial terms behind those paths, the repair priority on each handoff, the bandwidth committed on each link, or whether routing policy will keep essential traffic stable when one path fails. For a small provider, upstream diversity is partly a procurement problem: paying for enough capacity, using credible providers, and avoiding a false sense of redundancy created by two services that share the same transport. It is also an engineering problem: setting local preference, monitoring packet loss, maintaining route filters, watching for route leaks, and keeping router configuration under change control. None of those practices are visible on the CISMAN pages.

A robust local ISP would be able to explain how failures are compartmentalized. If a building drop is cut, only that customer or building should fail. If a street cabinet loses power, the affected cluster should be known and backup runtime should be predictable. If one upstream fails, the second path should carry essential traffic, perhaps with degraded performance but without full isolation. If a prefix is withdrawn by accident, route-origin controls and peer monitoring should catch the issue. If a technician is unavailable, there should be a second person or contractor with access to spares and site information. KAVKAZNET may have some or all of these practices. The public evidence does not document them, which is why the buyer-side posture should remain cautious.

The official site also leaves open the fixed-wireless question in the assignment's asset set. The reviewed public pages show internet access, cable installation and fibre laying, and they mention optional WiFi router equipment inside the customer premises. They do not provide a clear public statement that KAVKAZNET operates a fixed-wireless last-mile network, radio towers or sector antennas. For that reason, the article should not lean on tower-failure scenarios as if they are proven KAVKAZNET assets. A tower or radio-power outage is a general regional-ISP failure path, but for this specific company the better-supported physical story is wired access, customer drops, fibre-related construction and upstream routing. If future evidence shows wireless access, the risk view should add tower power, spectrum interference, line-of-sight and weather exposure. On the present record, those remain questions, not findings.

Power deserves the same evidence discipline. Every access network depends on electricity, but dependency is not the same as documented vulnerability. The public pages do not say whether KAVKAZNET has UPS units in access nodes, generator access, protected power at any core site, or battery monitoring. They do not even reveal the number or location of access nodes. The correct way to state the risk is conditional: if the company's access aggregation is concentrated in a small number of powered sites, then a local power incident can take down many customers unless backup power is tested and maintained. That is a standard engineering concern. It is not a confirmed incident history.

Unofficial market and routing signals should therefore remain signals. BGP.tools and IPinfo are useful because they independently surface the same basic shape: AS50712, Russia, three IPv4 originated prefixes, zero IPv6 visible, and an ISP or eyeball-network classification. PeeringDB's empty response is useful because it shows the lack of an easily located public interconnection profile. None of these pages can prove customer satisfaction, fault volume, local market share, revenue, or the practical quality of the support desk. They can guide questions, and they can prevent the analysis from relying only on the company's own site, but they cannot replace direct operating evidence.

The final procurement lens is service substitution. If KAVKAZNET is the only practical wired option for a building, a buyer may accept the uncertainty and mitigate it with a second mobile or satellite backup, local router failover and clear escalation contacts. If a national carrier is also available, the choice becomes a tradeoff between local support and the larger carrier's broader network resources. If KAVKAZNET is one of several local providers, the deciding facts should be route diversity, repair time, power backup and willingness to document coverage by address. The public record makes KAVKAZNET plausible as a primary local connection for ordinary residential use. It is not enough, by itself, to make the service a single-provider critical connection for a business or institution that cannot tolerate downtime.

There is a content-quality lesson in this case as well. A thin public footprint should not be padded with imagined infrastructure. It is tempting to turn every local ISP into a story about hidden backbone routes, towers, hardened shelters and regional recovery capacity. The record here does not support that flourish. The better editorial value is to show the exact distance between public facts and operational certainty. KAVKAZNET's office pages make the customer relationship visible. RIPE and third-party routing pages make the global reachability surface visible. The missing middle is where the risk sits: access cabinets, fibre entries, customer drops, power, spare parts, staff schedules and route handoffs. Naming that missing middle is more useful to readers than overstating what the company has proved.

The same restraint protects KAVKAZNET from unfair inference. A company can have no public PeeringDB profile and still be well connected for its customer base. It can have no public SLA and still repair faults quickly. It can have no visible IPv6 and still provide an acceptable everyday residential service. It can operate from a simple website and still have competent engineers. Public silence is not operational failure. But public silence does move the burden of proof. The more a customer depends on the connection, the more that customer needs direct answers from the provider rather than comfort from a brand name or a routing table. For low-risk residential use, the available evidence may be enough. For critical use, it is only the opening file.

The company itself would gain from publishing more of that information, even in a conservative format. A short public network-resilience note could state that customer availability varies by address, list the access technologies used, explain whether upstreams are physically diverse, identify support hours, describe backup-power practices in general terms, and name the route-origin security posture. It would not need to reveal sensitive maps. It would simply close the gap between "we provide access" and "we can explain what happens when access breaks." For a small ISP, that kind of disclosure can be commercially useful because it makes local proximity look like accountable operations rather than thin marketing.

Until then, KAVKAZNET should be read as an evidence-bounded local connectivity provider. The public facts support a real company, a Mineralnye Vody customer base, retail internet service, fibre-related activity, support channels, and an active AS50712 IPv4 footprint. The public facts do not support a high-confidence claim of broad regional coverage, physical redundancy, route independence, backup power or rapid repair capacity. That downgrade is not a dismissal. It is the difference between seeing the bill and understanding the network behind the bill. For KAVKAZNET's customers, the decisive infrastructure is where those two layers meet: the local cable and technician on one side, the upstream route and address plan on the other.