NTT DOCOMO BUSINESS e AS4713: o que uma identidade de rede ainda

Resumo

Segundo a NTT DOCOMO BUSINESS, a NTT Communications Corporation mudou de nome em 1º de julho de 2025. Registros atuais da APNIC, do RIPEstat e da JPNAP ligam, em camadas diferentes, o novo nome empresarial, a designação OCN e o AS4713. Já o PeeringDB ainda exibe um nome anterior. Essa combinação mostra bases mantidas para finalidades distintas; não autoriza tratar todas as denominações como se fossem um único certificado jurídico.
O AS4713 sustenta afirmações delimitadas sobre identidade de rede registrada, rotas observadas em uma data, uma autorização de origem verificada de forma pontual e controles de roteamento de um produto específico. Ele não comprova a propriedade de todos os prefixos observados, operação sem interrupções durante a mudança de nome, alcance universal, latência, disponibilidade para clientes ou qualidade do serviço.

Entrada no diretório: NTT DOCOMO Business, Inc

Nota sobre a imagem: a fotografia que acompanha o texto é uma reconstrução editorial sintética. Ela mostra uma profissional independente fictícia comparando registros sem marcas ao lado de um cabo de fibra óptica também sem marca. Não retrata funcionários, instalações, equipamentos ou dados de clientes da NTT DOCOMO BUSINESS, NTT Communications, OCN, APNIC ou JPNAP, nem um mapa real de rotas ou uma tela ao vivo do AS4713. Os papéis e o cartão são apenas ilustrativos e não comprovam identidade empresarial, propriedade de prefixos, validade de rotas, desempenho ou continuidade do serviço.

Análise

Um nome mudou; cada camada de registro continuou no próprio ritmo

A NTT DOCOMO BUSINESS usa a identidade atual em seu perfil público. A página informa que a NTT Communications Corporation passou a se chamar NTT DOCOMO BUSINESS, Inc. em 1º de julho de 2025. Antes dessa data, um comunicado do NTT Group havia anunciado a mudança planejada. Juntas, essas duas fontes da própria organização permitem uma formulação cuidadosa: a empresa afirma que a alteração anunciada entrou em vigor naquele dia.

O alcance dessa frase é menor do que pode parecer. As fontes examinadas não incluem, por exemplo, uma certidão independente de um registro público empresarial capaz de estabelecer todas as consequências jurídicas. Elas não provam que contratos, cadastros técnicos, contas e objetos de rede foram atualizados ao mesmo tempo. Tampouco descrevem aquisição, fusão, transferência de todos os ativos ou criação de uma nova sociedade. Por isso, a redação responsável fala da mudança de nome declarada pela empresa, sem atribuir ao episódio uma operação jurídica que esses documentos não demonstram.

Os registros públicos da internet também não funcionam como uma base única, sincronizada em um instante. A resposta RDAP atual da APNIC para a JPNIC sobre o número de sistema autônomo 4713 usa o nome OCN e menciona NTT DOCOMO BUSINESS, Inc. O RIPEstat apresenta uma identificação que também relaciona OCN ao novo nome. A lista de participantes da JPNAP associa NTT DOCOMO BUSINESS, OCN e AS4713 nos pontos de troca de tráfego de Tóquio e Osaka. O perfil do PeeringDB, em contraste, ainda mostra “NTT Communications Corporation (OCN)”.

Essa diferença não torna um registro automaticamente falso ou inútil. Cada serviço tem objetivo, responsável, ritmo de atualização e vocabulário próprios. Um perfil corporativo descreve a identidade atual segundo quem o publica. Um registro regional da internet documenta recursos numéricos. Um observador de rotas informa o que seus coletores viram em determinado momento. Um ponto de troca de tráfego divulga sua relação de participantes. Um diretório de interconexão ajuda redes a se encontrar e pode conter campos mantidos voluntariamente pelos próprios operadores.

A pergunta útil não é “qual página manda em todas as outras?”. É melhor perguntar: “para qual questão essa página foi criada, quando a informação foi observada e quem precisa reconciliá-la quando outro registro muda?”.

Essa distinção tem efeito prático. A área de compras precisa saber qual é a parte contratual exata. A equipe de redes precisa do sistema autônomo, dos prefixos permitidos e da política de roteamento. A equipe de segurança precisa de contatos atuais, autorizações de origem e regras de filtragem. Quem coordena um incidente precisa saber quem pode aprovar e desfazer uma mudança. Se todas as áreas guardarem apenas a palavra “NTT”, uma mudança de nome revelará o quanto esse rótulo coletivo deixa de explicar.

O significado de um número de sistema autônomo, sem complicação

Um número de sistema autônomo, geralmente abreviado como ASN, é um identificador público usado por uma rede que troca informações de roteamento com outras redes. O AS4713 é um desses números. Nos registros examinados, ele está associado a OCN e NTT DOCOMO BUSINESS. Não é número de registro empresarial, conta de cliente, endereço IP, número de série de roteador nem certificado de bom serviço.

A internet é formada por muitas redes operadas de maneira independente. Elas precisam dizer umas às outras quais blocos de endereços conseguem alcançar. O Border Gateway Protocol, ou BGP, transporta esses anúncios. De forma simplificada, uma mensagem diz: “este bloco de endereços pode ser alcançado por este sistema autônomo”. As demais redes recebem muitos anúncios, aplicam suas políticas e escolhem caminhos.

O ASN dá estabilidade a essa troca. Pessoas, produtos, marcas e nomes empresariais podem mudar sem exigir uma nova numeração de roteamento e uma virada mundial simultânea. Isso evita risco desnecessário. A mesma referência pode continuar útil para políticas, registros e observações enquanto as informações administrativas são atualizadas.

Estabilidade não equivale a prova de continuidade total. Encontrar o AS4713 em um registro hoje e numa observação de rotas ontem não demonstra que todos os pacotes de todos os clientes passaram sem interrupção durante a mudança de nome de julho de 2025. Não mostra que todos os sistemas internos adotaram a nova denominação no prazo nem que a mesma equipe aprovou todas as rotas. Mostra uma identidade pública de roteamento persistente, nos momentos e pelos métodos representados nas fontes.

Uma comparação simples ajuda. O número de uma linha ferroviária pode permanecer igual quando a operadora muda de nome. O número ajuda passageiros e sistemas de controle a reconhecer a linha. Ele não prova quem é dono de cada trecho, se todos os trens chegaram no horário ou se todos os contratos foram atualizados. Essas perguntas dependem de outros registros. Um ASN tem uma função igualmente delimitada no intercâmbio entre redes.

O registro RDAP da APNIC para a JPNIC é um livro de registros, não um mapa completo de propriedade

A APNIC é o registro regional da internet que atende a região da Ásia-Pacífico, e o endpoint consultado encaminha essa busca de um recurso japonês ao serviço RDAP da JPNIC. RDAP significa Registration Data Access Protocol. Ele fornece dados estruturados sobre recursos numéricos da internet sem exigir que pessoas e sistemas extraiam informações de uma página informal.

O objeto RDAP examinado da APNIC para a JPNIC identifica o AS4713, dá a ele o nome OCN, associa o registro ao Japão, indica que o objeto cadastral está ativo e inclui uma descrição com NTT DOCOMO BUSINESS, Inc. Trata-se de uma evidência primária forte para uma afirmação limitada: a camada cadastral atual do registro regional conecta essas denominações ao AS4713.

O registro não deve ser ampliado até virar uma declaração de que a empresa é proprietária legal de todo prefixo IP já observado com origem no AS4713. Redes podem anunciar espaço de endereços de clientes sob acordos documentados. Um provedor pode rotear endereços cujo cadastro pertence a outra organização. Prefixos podem mudar de origem durante migrações, mitigação de ataques ou alterações de serviço. Contatos administrativos e operacionais também podem ser diferentes.

A palavra “ativo” tem escopo específico. Ela descreve o estado do objeto cadastral; não é um monitor de disponibilidade. Um registro ativo pode coexistir com falha de roteamento, circuito de acesso rompido, problema de DNS, indisponibilidade de aplicação ou erro de configuração do cliente. Da mesma forma, uma página cadastral temporariamente inacessível não provaria que a rede em funcionamento deixou de existir.

É mais correto entender um registro como livro de anotações e coordenação. Ele ajuda a manter números únicos, nomes, identificadores, contatos e histórico de alterações. Isso favorece a responsabilização. Não substitui a rede que está realmente funcionando, os contratos que definem o serviço nem as medições que mostram se um cliente alcança uma aplicação.

O que as observações de rotas de 5 de agosto mostram

O RIPEstat reúne produtos baseados em registros e em observações de roteamento. Para o AS4713, foi examinado um resultado de prefixos anunciados numa janela de 5 de agosto de 2026, entre 00:00 e 16:00 UTC. A resposta continha 187 registros de prefixos observados: 181 IPv4 e seis IPv6.

Esse número só é útil acompanhado do método. O produto informa que exclui rotas vistas por menos de dez peers full-feed do RIPE RIS. Portanto, não se trata de uma lista de toda rota que possa existir em qualquer ponto da internet. É uma visão filtrada do que os coletores receberam segundo a regra declarada.

O resultado de status de roteamento para o retrato devolvido às 16:00 UTC mostrou o AS4713 visível em 326 de 326 peers IPv4 incluídos e em 322 de 322 peers IPv6 incluídos. Também relatou 181 prefixos IPv4, seis IPv6 e 122 vizinhos observados. A resposta registrou um aviso: o horário solicitado foi ajustado porque era posterior ao dado mais recente disponível. Um relatório responsável preserva o horário efetivo da observação e o aviso, em vez de apresentar o horário pedido como se estivesse garantido.

Seria tentador transformar a visibilidade completa dentro desse conjunto em “toda a internet alcançava o AS4713”. Isso estaria errado. Os denominadores são os participantes incluídos naquela visão do RIPE RIS, não todas as redes, dispositivos ou pessoas. Um coletor pode receber um anúncio enquanto um cliente específico não alcança um serviço por causa de falha no acesso local, filtro, congestionamento, DNS, firewall, servidor ou aplicação.

Os 122 vizinhos também não são automaticamente clientes pagantes, fornecedores contratados de trânsito ou pares sem cobrança. Diferentes serviços inferem relações de maneira distinta. Alguns caminhos aparecem apenas para determinados coletores. Os números podem variar conforme política de roteamento e cobertura de observação.

Assim, os 187 registros são evidência de atividade de roteamento observada, não cadastro de propriedade nem nota de qualidade. Eles respondem quais prefixos atenderam ao método daquele observador para o AS4713 naquela janela. Não respondem quem possui cada bloco, quem o utiliza, com que velocidade responde ou se cada rota estava autorizada corretamente.

Um resultado RPKI válido vale para uma combinação específica

O conjunto de evidências inclui também uma verificação pontual de origem de rota por meio da Resource Public Key Infrastructure, ou RPKI. O mecanismo permite que quem detém recursos de endereços publique uma declaração assinada chamada Route Origin Authorisation, ou ROA. Ela indica qual sistema autônomo pode originar determinado prefixo e, em alguns casos, até qual comprimento máximo.

A combinação consultada foi AS4713 com 61.207.0.0/16. O resultado voltou como válido por meio do validador Routinator e correspondeu a uma ROA com origem 4713 e comprimento máximo 16. Para essa consulta exata, é uma informação de segurança significativa.

Não é um certificado para todas as rotas ligadas ao AS4713. Uma rede que anuncia muitos prefixos pode ter ROAs diferentes, comprimentos máximos diferentes ou nenhuma ROA de cobertura para determinadas rotas. Autorizações podem ser criadas, alteradas ou removidas. Mudar o prefixo ou a origem já exigiria outra consulta.

A validação de origem tem outra limitação importante: ela verifica a relação entre um prefixo e o ASN que aparece na origem da rota. Não autentica todos os sistemas autônomos do caminho. Não prova que a fibra física está intacta, que o caminho tem baixa latência, que os pacotes não são descartados ou que a aplicação de destino funciona.

Uma descrição rigorosa diz: “esta combinação de origem e prefixo retornou como válida nesta verificação”, acompanhada de consulta, momento e validador. Dizer apenas “o AS4713 é seguro por RPKI” daria a uma amostra um alcance que ela não possui.

O trabalho operacional continua no inventário completo: blocos de endereços, permissões de clientes, objetos de rota, ROAs, comprimentos máximos, origens previstas, filtros e monitoramento. Uma amostra válida mostra que a relação pode ser verificada; não elimina a manutenção e a supervisão.

A documentação do produto mostra controles, não resultados em operação

A documentação de roteamento do Super OCN Flexible Connect oferece outra camada. Para o produto descrito, o lado OCN usa o AS4713. A página explica opções de roteamento estático ou BGP e apresenta possibilidades de uso de ASN do cliente e de endereços IP trazidos por clientes que atendam às condições.

O documento também publica limites concretos para esse serviço. O perfil BGP requer senha de autenticação MD5, define máximo de 1.000 prefixos e hold time mínimo de 30 segundos e descreve comunidades BGP usadas em controles de prioridade de tráfego. Na mesma página, LFS e BFD aparecem expressamente como não suportados.

Esses detalhes revelam o trabalho repetido por trás de uma conexão que pode parecer simples. Alguém precisa verificar se o ASN do cliente se qualifica. O espaço de endereços fornecido pelo cliente precisa ser validado. Limites de prefixos precisam ser definidos e revisados. O material de autenticação deve ser trocado e protegido. Comunidades permitidas precisam ser escolhidas, alterações testadas e anúncios inesperados monitorados.

Os números não devem ser lidos fora do contexto. O máximo de 1.000 prefixos não é o tamanho do AS4713; é uma proteção de uma sessão de roteamento nas condições documentadas. Um hold time mínimo de 30 segundos não é garantia de recuperação. O MD5 protege um mecanismo específico da sessão BGP; não torna o serviço inteiro imune a erros ou ataques.

BFD, sigla de Bidirectional Forwarding Detection, costuma ser usado para detectar falhas de caminho rapidamente. O fato de a página citada dizer que BFD não é suportado nesse produto não comprova serviço ruim. Significa que o planejamento de continuidade precisa usar os mecanismos realmente disponíveis, seus temporizadores, o monitoramento e a forma de escalonamento, sem presumir um recurso inexistente.

Uma documentação do fornecedor comprova o comportamento projetado e os controles publicados. Não é uma verificação independente de que todos os clientes configuraram tudo corretamente, todas as mudanças passaram por revisão ou determinado incidente cumpriu um compromisso contratual. Para avaliar resultados, o cliente precisa de suas configurações, registros, medições, chamados e testes.

A diferença entre PeeringDB e RIPEstat ensina mais do que uma falsa igualdade

O PeeringDB é um diretório mantido por operadores de rede para facilitar interconexões. O perfil examinado, identificado como rede 826, usa o nome antigo “NTT Communications Corporation (OCN)”, informa o ASN 4713 e descreve um provedor regional. Também lista pontos de interconexão e campos que podem ter datas de manutenção diferentes.

Na captura analisada, os contadores de prefixos IPv4 e IPv6 apareciam com valor zero. Ao lado disso, há a observação datada do RIPEstat com 181 registros IPv4 e seis IPv6. A interpretação correta não é que um serviço revelou uma queda da rede nem que o outro inventou rotas.

As fontes respondem a perguntas diferentes. O PeeringDB é um diretório operacional voluntário. Certos campos podem estar sem preenchimento, desatualizados ou voltados à descoberta de contatos, não à contagem ao vivo. Os valores do RIPEstat vêm de um método de observação em uma janela de tempo. Zero num campo de diretório pode significar “não informado aqui”, e não “não existe nada na rede”.

Esse contraste mostra por que sistemas automáticos precisam conhecer a semântica, não apenas copiar valores. Se os dois números forem colocados na mesma coluna chamada “quantidade de prefixos”, pode surgir um alerta falso. Uma estrutura melhor registra fonte, definição do campo, horário, modo de manutenção e confiança. Assim, a divergência pode ser encaminhada para análise sem declarar que uma das fontes está sempre errada.

A mudança de nome acrescenta outra dificuldade. Um nome empresarial antigo pode coexistir com informações de interconexão ainda úteis. Um nome atualizado pode coexistir com um campo operacional antigo. A reconciliação deve ocorrer campo por campo. Substituir todo nome antigo sem critério apaga a origem histórica; preservar cada nome antigo como se ainda fosse atual também engana.

A JPNAP liga os nomes num ponto de troca de tráfego, com limites claros

A lista atual de participantes da JPNAP relaciona NTT DOCOMO BUSINESS, OCN e AS4713 em seus pontos de troca de tráfego de Tóquio e Osaka. É uma ligação útil e atual entre o nome da empresa, o nome de serviço ou de rede e o ASN no contexto de uma infraestrutura de interconexão.

Um Internet Exchange, ou IX, é uma infraestrutura e um serviço por meio dos quais redes podem trocar tráfego. Participar pode facilitar a interconexão e oferecer um ponto público de contato operacional. Uma entrada na lista, porém, não revela todos os acordos privados, volumes de tráfego, preferências de caminho ou resultados de desempenho.

Estar presente em Tóquio e Osaka também não prova que um cliente específico tenha duas rotas fisicamente independentes. Duas sessões lógicas podem compartilhar entrada de prédio, circuito de transporte, energia, equipamento, fornecedor ou equipe operacional. Quem compra resiliência precisa mapear os próprios domínios de falha.

O registro da JPNAP é mais forte quando usado exatamente para o que exibe: no momento da consulta, a lista vinculava aquelas denominações e o AS4713 nos locais indicados. Ele não substitui contrato, topologia física nem medição ao vivo.

O AS4713 não representa toda rede que leva o nome NTT

Duas fontes ajudam a evitar um erro comum. Um artigo técnico da APNIC de 2023 diferencia o OCN doméstico, AS4713, da rede móvel AS9605 e da rede global GIN, AS2914. Uma página anterior da própria NTT também separa GIN AS2914 de OCN AS4713 ao descrever um serviço com dois sistemas autônomos.

O artigo da APNIC é uma análise histórica. Suas conclusões anteriores sobre topologia ou participação de usuários não devem ser reapresentadas como fatos atuais. A página do fornecedor não mostra data e tem finalidade comercial; portanto, não sustenta alegações de hoje sobre escala, qualidade ou posição no mercado. As duas ainda são úteis para um ponto mais estreito: “NTT” não é sinônimo de um único número de roteamento.

Isso importa em incidentes e verificações. Um traceroute que mostre AS2914 não deve ser descrito automaticamente como AS4713. Uma observação móvel relacionada ao AS9605 não deve ser atribuída à OCN. Um nome no nível do grupo também não determina qual rede, produto ou contrato está em análise.

Identificadores precisos reduzem atribuições equivocadas. Um alerta pode chegar à equipe responsável pelo ASN observado, e não a uma caixa postal corporativa genérica. Uma revisão de mudança pode consultar o inventário de prefixos correto. Um cliente pode verificar se o caminho de contingência realmente atravessa outra rede.

Como uma mudança de nome pode causar problemas operacionais

Mudar o nome parece uma tarefa administrativa, mas operações de rede dependem de nomes em muitos sistemas. Os registros públicos mostram apenas parte dessa superfície. Dentro de uma empresa, a mesma identidade pode aparecer em contratos, cobrança, certificados, listas de permissão, repositórios de políticas de rota, painéis de monitoramento, contatos de incidente, portais de fornecedores e evidências de auditoria.

Daí surgem vários modos de falha.

Primeiro, uma consulta de contato pode retornar o nome anterior e ser rejeitada por quem espera somente o novo. Durante um incidente, isso atrasa o acionamento mesmo que telefone e e-mail ainda funcionem.

Segundo, uma regra automática de conformidade pode comparar textos de forma literal. “NTT Communications Corporation” e “NTT DOCOMO BUSINESS, Inc.” seriam tratadas como organizações sem relação, gerando uma exceção falsa. Há também o risco oposto: uma regra ampla demais pode reunir todas as redes com marca NTT numa única entidade e aprovar um escopo maior do que o pretendido.

Terceiro, a documentação de roteamento pode usar o rótulo OCN enquanto o contrato usa o nome empresarial e a observação pública usa o ASN. Sem uma tabela confiável que ligue esses identificadores, alguém pode aprovar a lista errada de prefixos ou acionar a equipe errada.

Quarto, o espaço IP fornecido pelo cliente pode ser classificado incorretamente. Um prefixo originado pelo AS4713 pode pertencer ao cliente e estar autorizado apenas para aquele serviço. Copiar origens observadas para o inventário patrimonial do provedor pode criar uma falsa alegação de propriedade.

Quinto, metadados de segurança podem divergir. ROAs, objetos de rota, filtros e contatos às vezes ficam sob equipes diferentes. O nome empresarial pode ser atualizado numa interface enquanto a autorização operacional permanece igual. Isso pode ser legítimo, desde que a relação seja compreendida e auditável.

Sexto, painéis podem transformar uma diferença cadastral em incidente ou esconder um problema real. O campo de prefixos com zero no PeeringDB e as rotas observadas pelo RIPEstat mostram por que toda métrica precisa de fonte e definição. O alerta deve perguntar se a diferença era esperada antes de anunciar uma falha de rede.

A solução não é forçar todos os sistemas a exibir exatamente a mesma sequência de caracteres. O necessário é uma correspondência mantida entre nome atual, nome anterior, rótulo de serviço, ASN, identificadores cadastrais, prefixos relevantes, produto, parte contratual e responsáveis por escalonamento. Cada ligação deve ter fonte e data de revisão.

A automação desloca o trabalho; não elimina a responsabilidade

O BGP automatiza a troca de informações de alcance. Filtros podem rejeitar anúncios fora de uma política aprovada. Validadores RPKI podem classificar relações entre origem e prefixo. Sistemas de monitoramento detectam mudanças rapidamente. Essas ferramentas reduzem a repetição manual.

Ao mesmo tempo, criam trabalho de supervisão. Alguém define a política, aprova exceções, mantém o inventário e avalia se uma rota rejeitada indica ataque, autorização vencida ou mudança legítima de emergência. Alguém também testa a reversão.

Uma mudança de nome deixa clara essa divisão. As equipes de comunicação e do departamento jurídico atualizam a identidade empresarial. Especialistas em registros cuidam dos recursos numéricos e contatos. A equipe de redes administra sessões BGP e filtros. A equipe de segurança acompanha RPKI e origens inesperadas. O atendimento técnico verifica qual contrato e qual lista de prefixos se aplicam. As áreas de compras e auditoria preservam a sequência de evidências.

Se o sucesso for medido apenas pela quantidade de rotas processadas automaticamente, esse custo humano some do painel. Medidas melhores incluem volume de exceções, alertas falsos, tempo até identificar o responsável, sucesso na reversão, registros antigos e esforço para reconciliar uma mudança empresarial ou de produto.

O problema não é automatizar. Automação executa premissas codificadas em grande escala. Identificadores corretos e registros de escopo claro tornam essas premissas mais seguras. Uma identidade mal definida pode transformar um pequeno erro de dados em muitos erros repetidos de política.

Como quem não é especialista pode verificar uma alegação de serviço

Uma empresa não precisa transformar todo comprador em engenheiro de BGP. Perguntas simples ajudam a separar evidências concretas de promessas amplas.

Comece pela identidade. Qual empresa exata consta no contrato? NTT DOCOMO BUSINESS é a parte atual ou outra organização do grupo entrega o serviço? Quais nomes anteriores ainda podem aparecer em documentos técnicos? Quem confirma uma alteração?

Depois, identifique a rede. Qual ASN é esperado para o serviço? Trata-se de AS4713, AS2914, AS9605 ou outro número? A resposta muda conforme produto, região ou direção do tráfego?

Em seguida, examine os endereços. Quem detém os prefixos importantes para o cliente? Qual sistema está autorizado a originá-los? Há espaço IP fornecido pelo cliente? Onde estão ROAs, objetos de rota e registros de aprovação?

Pergunte também sobre controles. O serviço usa roteamento estático ou BGP? Quais limites de prefixos se aplicam? Como a sessão é autenticada? Quais comunidades são aceitas? Quais métodos de detecção de falha não são suportados? Quem pode alterar a configuração e como a mudança é revisada?

Defina como o resultado será medido. Visibilidade pública de rotas pode confirmar que coletores selecionados viram o ASN. Não comprova desempenho de aplicação. O cliente deve testar de locais relevantes até os destinos realmente usados, registrando horário, perda, latência, resolução de DNS, resposta da aplicação, contexto de rota e taxa de erro.

Por fim, teste a continuidade. O que ocorre se o circuito principal, um equipamento, um local ou uma rota for retirado? O tráfego segue por um caminho realmente separado? Quanto tempo a aplicação leva para se recuperar? Quem decide reverter? Uma discussão de mesa ajuda, mas um teste controlado é uma evidência mais forte.

Essas perguntas mantêm a proporção correta. Um registro comprova um fato cadastral. Um coletor comprova uma observação. Um documento de produto comprova um desenho publicado. Um teste do cliente comprova um resultado dentro de seu método e momento.

O que os registros públicos não estabelecem

Os registros examinados não estabelecem disponibilidade, latência, perda de pacotes, número de clientes ou participação de mercado do AS4713. Não provam que NTT DOCOMO BUSINESS detenha todos os 187 prefixos observados. Não mostram que cada anúncio do AS4713 tenha uma ROA válida.

Eles também não comprovam operação contínua e sem interrupções antes, durante e depois da mudança de nome de julho de 2025. As fontes foram coletadas em momentos diferentes e têm propósitos diferentes. Um identificador persistente e observações atuais sustentam continuidade de identidade, não um histórico completo de indisponibilidade.

A descrição da APNIC não vira um certificado soberano de propriedade. O PeeringDB não é inventário ao vivo de prefixos. Participação na JPNAP não é resultado de tráfego ou desempenho. Documentos do fornecedor não são verificação operacional independente.

Esses dados também não quantificam economia líquida de trabalho produzida pela automação de roteamento. As ferramentas automatizam tarefas repetidas, mas as fontes não medem horas gastas com desenho de políticas, exceções, reconciliação, monitoramento, incidentes e suporte ao cliente.

Esses limites fazem parte da conclusão. Eles evitam transformar um registro técnico útil numa promessa jurídica ou comercial muito maior do que a evidência permite.

A evidência que permanece útil depois da mudança de nome

Quando as camadas são mantidas separadas, ainda resta um quadro coerente.

A empresa afirma que NTT Communications Corporation mudou o nome para NTT DOCOMO BUSINESS, Inc. em 1º de julho de 2025. A resposta cadastral atual da APNIC para a JPNIC identifica o AS4713 ativo como OCN e menciona o novo nome. A visão capturada do RIPEstat mostra o AS4713 anunciado e registra um conjunto delimitado de prefixos e vizinhos. Uma combinação de prefixo e origem consultada retornou válida por RPKI. A documentação de produto identifica o AS4713 no lado OCN de um serviço e publica controles concretos. A lista da JPNAP liga o nome atual, OCN e AS4713 em Tóquio e Osaka.

O PeeringDB conserva um nome empresarial anterior e campos que não devem ser confundidos com inventário ao vivo.

Essa sequência mostra por que um ASN pode ser uma identidade operacional duradoura sem virar certificado universal. O número permite que registros, redes e observadores se refiram a um domínio de roteamento. Sua utilidade depende de pessoas manterem contatos, autorizações, políticas e correspondências corretas. A rede em funcionamento continua sendo a camada da realidade, mas só pode ser entendida e governada quando os registros preservam escopo e origem.

Para o leitor, a conclusão prática é modesta e sólida: dentro dos métodos apresentados, o AS4713 demonstra uma identidade de roteamento OCN reconhecível, registrada e observada. Ele não demonstra automaticamente toda afirmação jurídica, comercial ou de desempenho que possa aparecer ao lado do nome NTT.

NTT DOCOMO BUSINESS e AS4713: o que uma identidade de rede ainda comprova após a mudança de nome da empresa

Por que isso importa