Resumo

  • Sob interpretação classful, uma sub-rede Classe A podia parecer a rede pai completa e retirar seus outros componentes do caminho default.
  • Liberar o estoque exigia migração conjunta de registro, provedor, domínio cliente, pares, agregação e descarte dos espaços não implantados.
  • O RFC 2036 previu condições e riscos; não contou incidentes reais nem demonstrou sucesso universal.

Uma rota presente deixou de ser elegível

O RFC 2036 comentava uma recomendação potencial para que a IANA, por meio de registros delegados, começasse a alocar componentes ainda livres do espaço Classe A como prefixos classless. O problema surgiu porque a prática anterior tinha preservado uma ponte com o passado. Blocos CIDR eram frequentemente superblocos compatíveis de redes Classe C, enquanto endereços Classe A e B ainda respeitavam seus limites históricos.

Nessa arquitetura, um provedor sem tabela completa podia importar apenas um default e continuar classful. Outro provedor assumia a proxy aggregation de blocos contíguos. Era uma operação imperfeita, mas as fronteiras de alocação não desafiavam a classificação antiga.

Ao cortar um prefixo de um pai Classe A, a classificação passa a mentir. Um roteador que veja o default e uma sub-rede pode transformar o segundo anúncio em alcance para o pai inteiro. Destinos em outros componentes não necessariamente voltam ao default. A rota continua ativa; a interpretação da classe a torna inelegível.

Por isso o RFC exigiu protocolos classless também dos provedores que dependiam de default. A proxy aggregation deixava de bastar. A disponibilidade administrativa de um bloco precisava ser acompanhada por software capaz de conservar o comprimento do prefixo.

O default de sub-rede precisou apontar para o lado oposto

Para um domínio cliente não transitivo, a exceção classful continha uma inversão. Em blocos alinhados às classes, um subnet default explícito não devia apontar para o provedor, para evitar loop na fronteira. Com um componente classless de Classe A, o RFC 2036 determinava que esse default seguisse o default geral rumo ao provedor.

A direção correta não eliminava os vazamentos. Rotas explícitas de sub-redes podiam chegar ao provedor, que passava a formar o agregado correto. Se o provedor fizesse proxy aggregation de todo o bloco alocado e devolvesse ao cliente o tráfego de um componente não implantado, o pacote circularia na interface. Se roteasse apenas componentes implantados, o tráfego para o buraco seguiria defaults até encontrar um ponto sem default e ser descartado.

Daí a recomendação de rotas sink para todos os componentes não implantados. O agregado e o sink respondem a perguntas diferentes. Um anuncia uma cobertura resumida; o outro impede que essa cobertura prometa uma saída onde não há destino. Nem um arquivo de configuração comprova que ambos entraram na FIB.

Multi-homing tornou a compatibilidade transitiva

Uma rede desconectada podia continuar classful. Uma rede com um único provedor classless podia usar a exceção se orientasse corretamente seu subnet default. A segunda conexão quebrava essa simplicidade: provedores diferentes poderiam anunciar partes diferentes do mesmo pai, obrigando o IGP interno a distinguir prefixos.

Conexões de peer espalhavam a obrigação. No exemplo do RFC, os stubs classless X e Y estão ligados por Z, que usa roteamento classful e oferece trânsito entre eles. X anuncia um componente; Z entende a Classe A completa e a anuncia a Y. O anúncio supera o default que Y recebeu de seu provedor. Todo o tráfego para o pai segue até X, que descarta o que não é local.

Não é necessário que um protocolo falhe. Cada elemento pode obedecer ao seu modelo e, mesmo assim, a combinação produz o buraco. Uma topologia nova pode invalidar uma exceção que parecia segura quando havia só um enlace.

A ordem de alocação passou a selecionar prontidão

O documento sugeriu começar por ambientes com IGP classless, ou domínios isolados e clientes classful com conexão única a um provedor classless e subnet default voltado para fora. Produtos deveriam expor explicitamente os modos classless e classful, inclusive a escolha entre seguir o default e usar um sink. Hosts precisariam compreender prefixo local, não apenas a decomposição classe, sub-rede e host.

O RFC 2050, publicado no mês seguinte, afirmou que as atribuições pressupunham VLSM e tecnologias classless e que pedidos baseados em uso classful não seriam considerados. A regra administrativa aproximava-se do requisito técnico, mas não auditava a implantação de cada destinatário.

O grupo ALE forneceu o contexto de pressão. Sua carta tratava de expectativa de vida do IPv4, utilização, políticas de alocação, contagem de rotas, recuperação e renumeração. O RFC 2036 relatou a preocupação com o consumo do espaço Classe C e a reserva ainda grande na metade superior da Classe A. Não publicou a série de dados da ALE nem resultados operacionais.

A conclusão histórica não é um censo retroativo

O RFC nasceu Informational, hoje é Historic e não possui errata registrada. Em 2006, o RFC 4632 justificou a mudança dizendo que o CIDR estava plenamente implantado e que já havia mais de seis anos de experiência em alocações classless de espaço historicamente Classe A. Isso registra a avaliação posterior da comunidade técnica; não identifica operadores, versões, taxas de falha ou causalidade.

O RFC 4632 também preserva a regra geral para buracos: quem origina um agregado deve descartar no destino nulo os pacotes que casem com o agregado, mas não com uma rota mais específica. O princípio é a continuação arquitetural do sink do RFC 2036. O registro atual da IANA e os documentos sobre os últimos /8 encerram o estoque descrito em 1996, sem fornecer estatística sobre a transição.

Uma reconstrução precisa de seis recibos separados: prefixo alocado; default e política do provedor; IGP e subnet default do cliente; gatilho do agregado e seus sinks; preservação de máscara em cada peer; e next hop ou descarte observado. A primazia do código em execução de Heng Lu não diminui o registro. Ela impede que a coordenação administrativa seja tratada como prova automática de forwarding.

Fontes