NTT DOCOMO BUSINESS and AS4713: What a Network Identity Still Proves After a Company Rename

Summary

NTT DOCOMO BUSINESS says NTT Communications Corporation changed its name on July 1, 2025. Current APNIC, RIPEstat and JPNAP records connect the newer company label, OCN and AS4713 at different record layers, while PeeringDB still displays an older name. That mixture is evidence of records maintained for different purposes, not permission to treat every label as one legal certificate.
AS4713 can support a bounded account of registered network identity, observed routes, one checked route-origin authorisation and product-specific routing controls. It cannot prove ownership of every observed prefix, uninterrupted operation through the rename, customer availability, universal reachability, latency or service quality.

Directory entry: NTT DOCOMO Business, Inc

Image note: The accompanying photograph is a synthetic editorial reconstruction. It shows a fictional independent analyst comparing unbranded records beside an unbranded fibre cord. It does not depict NTT DOCOMO BUSINESS, NTT Communications, OCN, APNIC or JPNAP staff, premises, equipment, customer data, an actual route map or a live AS4713 screen. The papers and card are illustrative and do not prove company identity, prefix ownership, route validity, performance or service continuity.

Analysis

One name changed; several record layers kept moving at their own speed

NTT DOCOMO BUSINESS presents itself as the current company identity on its public company profile. The profile says NTT Communications Corporation changed its name to NTT DOCOMO BUSINESS, Inc. on July 1, 2025. An NTT Group release published before that date had announced the planned change. Taken together, these issuer sources support a careful statement: the company says the announced name change took effect on that date.

That sentence is narrower than it may first appear. The reviewed sources do not include an independent government corporate-register extract establishing every legal consequence of the change. They do not prove that every contract, technical database, account name or network object was updated at midnight. They do not describe an acquisition, merger or transfer of every asset. The accurate public wording is therefore about the company’s stated name change, not a larger legal conclusion that the sources do not contain.

The Internet’s public records also do not update as one synchronized database. The current APNIC-to-JPNIC RDAP response for autonomous system number 4713 uses the name OCN and refers to NTT DOCOMO BUSINESS, Inc. RIPEstat returns a holder label that also connects OCN with the newer company name. JPNAP’s participant roster maps NTT DOCOMO BUSINESS, OCN and AS4713 at its Tokyo and Osaka exchanges. PeeringDB’s network profile, by contrast, still uses “NTT Communications Corporation (OCN).”

None of those differences automatically makes a record fraudulent or useless. Each service has its own purpose, owner, update cycle and vocabulary. A corporate profile describes the issuer’s current company identity. A regional Internet registry records number-resource information. A route observer reports what selected collectors saw. An Internet exchange publishes a participant roster. An interconnection directory helps networks find one another and may contain operator-maintained fields that age at different speeds.

The useful question is not “Which single page is sovereign?” It is “What question was this page designed to answer, when was it observed, and who must reconcile it when another record changes?”

That distinction matters to ordinary business operations. A procurement team needs the legal or contractual party. A network engineer needs the autonomous system, permitted prefixes and routing policy. A security team needs current contacts, route-origin authorisations and filtering rules. An incident manager needs the person who can approve a change and the team that can reverse it. If all four teams store only “NTT,” a company rename can expose how little the shared label actually says.

What an autonomous system number means in plain language

An autonomous system number, usually shortened to ASN, is a public number used by a network that exchanges routing information with other networks. AS4713 is one such number. It is associated in the reviewed records with OCN and NTT DOCOMO BUSINESS. It is not a company registration number, a customer account, an IP address, a router serial number or a certificate of good service.

The Internet is made of many independently operated networks. They need a way to tell one another which blocks of addresses they can reach. The Border Gateway Protocol, or BGP, carries those announcements. A simplified announcement says, “This block of addresses can be reached through this autonomous system.” Other networks receive many such announcements, apply policy and select paths.

The ASN helps make that exchange manageable. It gives routing policy a stable identifier even when people, products, brands or company names change. That stability is useful. If every corporate rebranding required a new routing number and a simultaneous global cutover, the operational risk would be enormous. A continuing ASN can preserve a recognizable policy and observation point while administrative records are updated.

Stability is not the same as proof of continuity. Seeing AS4713 in a registry today and in a route observation yesterday does not demonstrate that every customer packet flowed without interruption across the July 2025 name change. It does not show that all internal systems used the new label on time. It does not establish that the same team approved every route. It shows a persistent public routing identity at the times and through the methods represented by the sources.

An analogy helps. A railway line number may remain the same when the operator changes a company name. The line number helps passengers and control systems identify the service. It does not prove who owns every piece of track, that every train ran on time, or that every contract was updated. Those questions need different records. An ASN works in a similarly bounded way for inter-network routing.

The APNIC-to-JPNIC RDAP record is a ledger entry, not a complete ownership map

APNIC is the regional Internet registry serving the Asia-Pacific region, and the reviewed APNIC endpoint redirects this Japanese resource query to JPNIC’s RDAP service. RDAP stands for Registration Data Access Protocol. It provides structured registration data for Internet number resources without requiring software to scrape an informal webpage.

The reviewed APNIC-to-JPNIC RDAP object identifies AS4713, names it OCN, places it in Japan, marks the registry object active and includes a description referring to NTT DOCOMO BUSINESS, Inc. This is strong primary evidence for a bounded claim: the current RIR registration layer connects those labels to AS4713.

The record should not be stretched into a declaration that the company legally owns every IP prefix ever observed behind AS4713. Networks can originate address space held by customers under documented arrangements. A company can provide routing for addresses whose registration sits elsewhere. Prefixes can move between origins during migrations, mitigation or service changes. Registry contacts and operational contacts may also differ.

The word “active” has a particular scope. It describes the registry object’s status. It is not an uptime monitor. An active aut-num record can coexist with a routing incident, an access-circuit failure, a domain-name problem, an application outage or a customer configuration error. Conversely, a temporarily unreachable registry webpage would not prove that the running network disappeared.

This is why a registry works best as a ledger and recordkeeper. It helps preserve uniqueness, names, identifiers, contacts and change history. It supports accountability. It does not replace the network that is actually running, the contracts that define service, or the measurements that show whether a customer can reach an application.

What the August 5 route observations show

RIPEstat provides data products built from registry information and routing observations. The reviewed evidence includes an announced-prefixes result for AS4713 over an August 5, 2026 window from 00:00 to 16:00 UTC. The returned data contained 187 observed prefix entries: 181 IPv4 and six IPv6.

That number needs its method attached. The data product notes that results exclude routes seen by fewer than ten RIPE RIS full-feed peers. In other words, the result is not a list of every route that might exist at any corner of the Internet. It is a filtered view based on what the service’s collectors received under its stated rule.

The routing-status result for the returned 16:00 UTC snapshot reported AS4713 visible through 326 of 326 included IPv4 peers and 322 of 322 included IPv6 peers. It also reported 181 IPv4 prefixes, six IPv6 prefixes and 122 observed neighbours. Those figures describe one collector view. The service can adjust a requested timestamp to the latest data available, so a responsible record keeps the returned observation time and any warning rather than presenting a requested time as if it were guaranteed.

It is tempting to convert complete visibility among the included peers into “the entire Internet could reach AS4713.” That would be wrong. The denominators are the peers included in that RIPE RIS view, not every network, device or user. A route collector can receive an announcement even when a particular customer cannot reach a service because of a local access failure, filtering, congestion, DNS, firewall policy, server failure or application error.

The observed-neighbour count also needs care. A BGP neighbour in an observed topology is not automatically a paying customer, a contracted transit supplier or a settlement-free peer. Relationships can be inferred differently by different services. Some paths are visible only through particular collectors. Numbers can change with routing policy and observation coverage.

The 187 prefixes are therefore evidence of observed routing activity, not a property register and not a quality score. They answer a useful question: which prefix records met this observer’s method for AS4713 during this window? They do not answer who owns each address block, who uses it, how fast it responds or whether every route was correctly authorised.

One valid RPKI result is one valid tuple

The reviewed evidence also includes one checked route-origin relationship using RPKI, the Resource Public Key Infrastructure. RPKI allows the holder of address resources to publish a signed statement called a Route Origin Authorisation, or ROA. A ROA says that a specified autonomous system is authorised to originate a specified prefix, sometimes down to a stated maximum prefix length.

The checked pair was AS4713 and 61.207.0.0/16. The returned validation result was valid through the Routinator validator and matched a ROA with origin 4713 and maximum length 16. That is meaningful security metadata for that exact query.

It is not a certificate for every route associated with AS4713. A network that announces many prefixes may have different ROAs, different maximum lengths or no covering ROA for some routes. Authorisations can be created, changed or withdrawn. The result can also differ if the queried prefix or origin changes.

Origin validation has another important limit: it checks the relationship between a prefix and the ASN at the route’s origin. It does not authenticate every autonomous system in the path. It does not prove that the physical fibre is intact, that the chosen route is low-latency, that packets are not dropped, or that the application at the destination works.

A useful report therefore says, “This origin-prefix tuple returned valid at this check,” and then keeps the query, time and validator. It does not say, “AS4713 is RPKI secure,” as if one result covered the whole network forever.

For an operator, the work lies in maintaining the complete relevant set: address holdings, customer permissions, route objects, ROAs, maximum lengths, intended origins, filters and monitoring. A valid sample shows that the system can be checked. It does not remove the need for inventory and supervision.

Product documentation shows controls, not production outcomes

NTT’s Super OCN Flexible Connect routing documentation provides another evidence layer. For the product described on that page, the OCN side uses AS4713. The document describes static routing or BGP choices and gives options for customer autonomous-system use and qualifying customer-provided IP space.

It also publishes concrete configuration constraints for that service. The BGP profile requires an MD5 authentication password, lists a maximum-prefix value of 1,000 and a minimum hold time of 30 seconds, and documents BGP communities used for traffic-priority controls. The same product page says LFS and BFD are not supported.

These details matter because they reveal the repeated work behind an apparently simple connection. Someone must check whether a customer ASN is eligible. Someone must validate customer-provided address space. Someone must set and review prefix limits. Someone must exchange and protect authentication material. Someone must decide which communities are allowed, test policy changes and monitor for unexpected announcements.

The numbers should not be misread. A maximum-prefix value of 1,000 is not the size of AS4713. It is a product-specific guardrail for a routing session under the documented conditions. A 30-second minimum hold time is not a recovery guarantee. It is one protocol setting within a larger detection and reconvergence process. MD5 protects a particular BGP session mechanism; it does not make the entire service immune to mistakes or attacks.

BFD, or Bidirectional Forwarding Detection, is a mechanism often used to detect path failures quickly. The cited page says BFD is not supported for this product. That absence does not prove poor service. It means continuity planning must rely on the actual supported mechanisms, timers, monitoring and escalation path rather than assuming a feature exists.

Issuer documentation is evidence of intended product behaviour and available controls. It is not independent proof that every customer configured them correctly, that every change was reviewed, or that a particular incident met a service-level commitment. To establish those outcomes, a customer needs its configuration, logs, measurements, tickets and test results.

The PeeringDB and RIPEstat difference is informative

PeeringDB is an operator-maintained directory used by networks for interconnection. The reviewed profile for network 826 uses the legacy label “NTT Communications Corporation (OCN),” identifies ASN 4713 and describes a regional network service provider. It lists interconnection entries and contains fields updated at different times.

The same profile displayed zero values for IPv4 and IPv6 prefix counters in the captured view. That sits beside a dated RIPEstat observation of 181 IPv4 and six IPv6 prefix entries. The responsible interpretation is not that one source exposed an outage or that the other fabricated routes.

The two services answer different questions and maintain their fields differently. PeeringDB is a voluntary operational directory. Some fields may be stale, unused or maintained for discovery rather than live counting. RIPEstat’s figures come from a route-observation method and time window. Zero in a directory field can mean “not populated here,” not “nothing exists in the network.”

This is a valuable example of why automated data pipelines need semantics, not just values. A system that copies both numbers into one column called “prefix count” may create a false alert. A better system records the source, field definition, observation time, maintenance model and confidence. It can then flag the difference for review without declaring either source universally wrong.

The company rename adds another dimension. A stale name can coexist with useful current interconnection data. An updated name can coexist with an old operational field. Reconciliation should be field by field. Replacing every old label blindly may erase provenance; preserving every old label as current may mislead readers.

JPNAP connects the labels at an exchange, within limits

JPNAP’s current participant roster maps NTT DOCOMO BUSINESS, OCN and AS4713 at its Tokyo and Osaka exchanges. This provides a useful present-day link between the current company name, the service or network label and the ASN in an Internet-exchange context.

An Internet exchange, or IX, is a facility and service through which networks can exchange traffic. Participation can make interconnection easier and can provide a public operational contact point. A roster entry does not disclose every private agreement, traffic volume, path preference or performance result.

Presence in both Tokyo and Osaka also does not prove that a particular customer has geographically separate paths. Two logical sessions can share a building entrance, transport circuit, power source, device, operations team or upstream dependency. A customer buying resilience must trace its own failure domains.

The JPNAP record is strongest when used for exactly what it shows: at the time checked, the roster linked those labels and AS4713 at those exchange locations. It is not a substitute for a contract, a physical topology or a live traffic measurement.

AS4713 is not every NTT network

Two reviewed records help prevent a common naming error. A 2023 APNIC technical article distinguishes domestic OCN AS4713 from mobile AS9605 and global GIN AS2914. An older issuer product page also distinguishes GIN AS2914 from OCN AS4713 in a dual-AS service description.

The APNIC article is historical analysis, so its past topology or user-share conclusions should not be repeated as current facts. The issuer page is undated marketing material, so it should not support current claims about scale, quality or market position. Both are still useful for the narrower point that “NTT” is not one routing number.

This matters during incidents and due diligence. A traceroute that contains AS2914 should not automatically be described as AS4713. A mobile-network observation involving AS9605 should not be assigned to OCN. A corporate name at group level does not tell a reader which operating network, product or contract is in scope.

Precise ASN labels reduce false attribution. They also make automation safer. An alert can route to the team responsible for the observed ASN rather than a generic corporate mailbox. A change review can check the correct prefix inventory. A customer can ask whether its backup path truly crosses a different network.

What a company rename can break operationally

A rename sounds administrative, but network operations depend on names appearing in many systems. The public records in this case reveal only part of that surface. Inside an operator or customer, the same identity may appear in contracts, billing accounts, certificate records, allowlists, route-policy repositories, monitoring dashboards, incident contacts, vendor portals and audit evidence.

Several failure modes follow.

First, a contact lookup may return the old company name and be rejected by someone who expects the new one. During an incident, that can delay escalation even if the phone number or mailbox still works.

Second, an automated compliance rule may compare names literally. “NTT Communications Corporation” and “NTT DOCOMO BUSINESS, Inc.” may be treated as unrelated, producing a false exception. The opposite risk also exists: a broad rule may collapse every NTT-branded network into one entity and approve more scope than intended.

Third, route-policy documentation may use a product label such as OCN while contracts use the company name and public observations use the ASN. If the relationship among those identifiers is not recorded, a reviewer may approve the wrong prefix list or contact the wrong team.

Fourth, customer-provided IP space can be misclassified. A prefix originated by AS4713 may be a customer resource authorised for that service. Copying observed origins into a company asset register could create a false ownership claim.

Fifth, security metadata can drift. ROAs, route objects, filters and contact records may be maintained by different people. A company name can be updated in one interface while the operational authorisation remains unchanged. That can be legitimate, but only if the relationship is understood and auditable.

Sixth, dashboards can turn a record mismatch into an incident or hide a real one. PeeringDB’s zero prefix field and RIPEstat’s observed routes demonstrate why every metric needs a source definition. An alert should ask whether the difference is expected before declaring a network failure.

The solution is not to force every system to display one identical string. It is to maintain a crosswalk: current company name, former name, service label, ASN, registry handles, relevant prefixes, product, contract party and escalation owners. Each link should have a source and review date.

Automation moves the work; it does not erase responsibility

BGP automates the exchange of reachability information. Route filters can automatically reject announcements outside an approved policy. RPKI validators can classify origin-prefix relationships. Monitoring can detect changes within seconds. Those tools reduce repeated manual processing.

They also create supervision work. Someone decides the policy. Someone approves an exception. Someone maintains the source inventory. Someone checks whether a route rejected as invalid reflects an attack, an expired authorisation or a legitimate emergency change. Someone tests rollback.

A corporate rename makes the distribution visible. Communications and legal teams update company identity. Registry specialists maintain number-resource contacts. Network engineers manage BGP sessions and filters. Security teams monitor RPKI and unexpected origins. Customer teams verify which contract and prefix list apply. Procurement and audit teams preserve the evidence chain.

If success is measured only by the number of routes processed automatically, these human costs disappear from the dashboard. A better measure includes exception volume, false alerts, time to identify the responsible owner, rollback success, stale records and the time required to reconcile a company or product change.

The point is not that automation is bad. It is that automation executes encoded assumptions at scale. Accurate identifiers and bounded records make those assumptions safer. Unclear identity can turn a small data error into repeated policy errors across many systems.

How a non-specialist can verify a service claim

A business buyer does not need to become a BGP engineer to ask useful questions. The evidence layers can be translated into a practical checklist.

Start with identity. What exact company is named in the contract? Is NTT DOCOMO BUSINESS the current party, or does another group entity supply the service? Which former names may still appear in technical records? Who confirms changes?

Then identify the network. Which ASN is expected for the service? Is it AS4713, AS2914, AS9605 or another number? Does the answer change by product, region or traffic direction?

Next identify the addresses. Who holds the customer prefixes? Which system is authorised to originate them? Are customer-provided addresses involved? Where are the ROAs, route objects and approval records?

Ask about routing controls. Is the service static or BGP? What prefix limits apply? How is the session authenticated? Which communities are supported? Which failure-detection methods are not supported? Who can change the configuration, and how is it reviewed?

Ask how success is measured. Public route visibility can confirm that selected collectors see the ASN. It cannot prove application performance. A customer should test from relevant sites to relevant endpoints, recording time, loss, latency, DNS resolution, application response, route context and error rate.

Finally, test continuity. What happens if the primary circuit, device, location or route is withdrawn? Does traffic move to a genuinely separate path? How long does the application take to recover? Who decides to roll back? A tabletop answer is useful; a controlled test is stronger.

These questions keep the evidence proportional. A registry proves a registry fact. A route collector proves an observation. A product document proves a published design. A customer test proves an outcome within its method and time.

What the public record does not establish

The reviewed public record does not establish uptime, latency, packet loss, customer count or market share for AS4713. It does not prove that every one of the 187 observed prefixes is held by NTT DOCOMO BUSINESS. It does not show that every AS4713 announcement has a valid ROA.

It does not prove continuous, uninterrupted operation before, during and after the July 2025 name change. The records sampled different times and purposes. A continuing identifier and current observations support continuity of identity, not a complete outage history.

It does not turn the APNIC holder description into a sovereign legal ownership certificate. It does not make PeeringDB a live prefix inventory. It does not make JPNAP participation a traffic or performance result. It does not make issuer documentation independent operational verification.

It also does not quantify net labour savings from routing automation. The tools clearly automate repeated steps, but the reviewed sources do not measure the hours spent on policy design, exceptions, reconciliation, monitoring, incidents or customer support.

These nonclaims are part of the result. They prevent a useful technical record from becoming a broader commercial or legal promise.

The evidence that survives the rename

After keeping the layers separate, a coherent picture remains.

The company says its name changed from NTT Communications Corporation to NTT DOCOMO BUSINESS, Inc. on July 1, 2025. The current APNIC-to-JPNIC registry response identifies active AS4713 as OCN and refers to the newer company name. RIPEstat’s captured view shows AS4713 announced and records a bounded set of prefixes and neighbours. One checked prefix-origin pair returned RPKI-valid. Product documentation identifies AS4713 as the OCN-side ASN for a described service and publishes concrete routing controls. JPNAP’s roster connects the current company label, OCN and AS4713 at Tokyo and Osaka.

PeeringDB retains a legacy company label and fields that should not be mistaken for a live inventory.

That chain shows why an ASN can be a durable operational identity without becoming a universal certificate. The number helps registries, networks and observers refer to a routing domain. Its usefulness depends on people keeping contacts, authorisations, policies and crosswalks accurate. The running network remains the reality layer, but it can be understood and governed only when its records preserve scope and provenance.

For a reader, the practical conclusion is modest and strong: AS4713 still proves that a recognizable OCN routing identity is registered and observed under the stated methods. It does not prove every commercial, legal or performance claim that might be placed beside the NTT name.