Resumo

  • A RFC 4008 colocou interfaces, categorias de serviço e parâmetros configuráveis no centro da gestão de NAT; a RFC 7658 explica por que essa estrutura não servia bem a muitas implementações.
  • A NATV2-MIB reduziu a configuração compartilhada e ampliou a observação de instâncias lógicas, domínios de endereço, assinantes, pools e estado.

O primeiro passo era cadastrar uma interface

Na RFC 4008, o exemplo de configuração por SNMP começa com uma entrada em natInterfaceTable. O gestor precisa conhecer um ifIndex e dizer se aquela interface está no domínio privado ou público. Em seguida, adiciona mapas de endereço para a mesma interface e define tempos limite. A tradução aparece dentro de uma hierarquia cujo ponto inicial é físico.

O raciocínio é compreensível: pacotes entram e saem por interfaces, e a equipe de rede pode usar esses limites para distinguir domínios. A RFC 4008 formalizou tabelas para interfaces, mapas, vínculos de endereço e de endereço/porta, além de sessões que conectam a visão privada à pública. Alguns objetos serviam para configuração; outros eram derivados e descreviam vínculos ou sessões observados. A MIB pretendia oferecer configuração e monitoramento de NAT em um mesmo contrato. RFC 4008, seções 1 e 4

O problema não estava na quantidade de tabelas. Estava no que elas obrigavam uma implementação a representar. Um serviço de tradução pode ser lógico e atravessar várias interfaces. Um vínculo pode pertencer a um conjunto de interfaces, e não a uma única. Um sistema pode não guardar a associação que a MIB exige. Nesse caso, a estrutura de gerenciamento deixa de descrever a implementação e passa a pedir que ela se adapte à estrutura da MIB.

A norma registra o desajuste

A RFC 7658 explica por que os objetos da RFC 4008 foram marcados como obsoletos. Segundo o documento, os algoritmos e estruturas de dados de NAT variavam muito. Isso produzia parâmetros de configuração incompatíveis entre implementações; poucas podiam alegar conformidade integral. Mesmo em modo de leitura, parâmetros como tempos limite continuavam difíceis de padronizar, e poucos equipamentos podiam reivindicar conformidade básica. A lição indicada pelos autores foi tornar a MIB o mais somente de leitura possível e não usá-la para expor a configuração do NAT. RFC 7658, seção 3

A dependência de ifIndex era uma questão de arquitetura. A RFC 7658 diz que muitas implementações não mantinham a interface associada a uma tradução ou ligavam um mapa a várias interfaces. Como a RFC 4008 organizava mapas e estado ao redor da interface, esses sistemas não conseguiam preencher o modelo naturalmente. A conclusão dos autores foi clara: NAT é uma função lógica que pode ser independente das interfaces.

As categorias e os números de protocolo eram outro ponto em que uma lista comum pretendia mais do que os produtos podiam oferecer. A RFC 4008 tinha quatro categorias de serviço — basicNat, napt, bidirectionalNat e twiceNat. A RFC 7658 as considera mal definidas: implementações podiam usar categorias diferentes ou nenhuma. Essas categorias não são as classificações de NAT em cone da RFC 3489; são os rótulos próprios da MIB antiga. A versão seguinte usa a terminologia de comportamentos da RFC 4787. Ela também troca a enumeração fechada other, ICMP, UDP e TCP por números de protocolo da IANA, evitando uma lista paralela que não representava protocolos como DCCP e SCTP.

Um sucessor com outra finalidade

Em 2015, a transição foi dividida em dois documentos. A RFC 7658 preserva as definições da RFC 4008, mas marca os objetos como deprecated. A RFC 7659 define a NATV2-MIB. Os identificadores antigos não recebem outro significado por baixo do mesmo nome. RFC 7658 RFC 7659

A NATV2-MIB foi desenhada sobretudo para monitorar. A informação de configuração em modo de leitura fica restrita ao contexto necessário para interpretar estado e estatísticas. A configuração gravável é removida, salvo controles de notificação e quotas de recursos NAT. Não é uma ausência completa de controle: o operador ainda pode definir limites protetivos. O que deixa de existir é a promessa de uma única interface de configuração para mecanismos NAT diferentes.

O eixo passa a ser a instância NAT lógica. Os mapas deixam de depender de uma interface como chave organizadora. O modelo admite várias instâncias em um dispositivo e um número arbitrário de domínios de endereço; também adiciona tabelas de assinantes, pools, protocolos, estado, estatísticas e notificações. Isso dá espaço a cenários de CGN, nos quais vários assinantes compartilham endereços e portas públicos e os limites de recursos precisam ser observados por instância.

A RFC 7659 também revisa a indexação dos mapas de porta para facilitar a busca do extremo interno a partir de parâmetros do pacote observáveis do lado externo. Esse caminho de consulta ajuda na gestão e na investigação; não comprova quem gerou o tráfego, que um pacote chegou ao destino ou que uma aplicação funcionou. RFC 7659, seções 2 e 3

A RFC 6888 ajuda a explicar a relevância das dimensões de assinante e recurso. Um CGN compartilha portas e estado entre assinantes; limites por assinante podem conter o consumo excessivo de um recurso comum. A NATV2-MIB consegue representar limites e parte do estado associado. Os documentos não mostram quais operadores aplicaram esses objetos, que valores escolheram ou quais foram os resultados. RFC 6888, seções 4 e 5

O que a mudança permite afirmar

A história da MIB de NAT é uma correção de abstração. A RFC 4008 tentou tornar a tradução configurável por meio de uma hierarquia comum de tabelas. A RFC 7658 registrou que as interfaces, categorias e parâmetros da primeira versão não se ajustavam a muitas implementações. A RFC 7659 reduziu a superfície de escrita comum e ampliou a descrição das instâncias e de seus recursos.

A conclusão precisa ficar dentro desse limite: o modelo de gestão mudou para representar melhor uma variedade de implementações. Isso não demonstra que todos os fabricantes adotaram NATV2-MIB, que ela se tornou universal ou que melhorou o desempenho da tradução. A RFC 7659 afirma que a primeira MIB foi pouco implementada, mas não oferece uma porcentagem nem mede a adoção da sucessora.

A fronteira com firewall também é explícita. As RFCs 4008 e 7658 dizem que as MIBs não cobrem funções de firewall e não devem ser usadas para configurá-las ou monitorá-las. Uma linha de tradução não é uma regra de filtragem.

Uma linha de gestão tampouco é um resultado de serviço. Um pool configurado não é um mapeamento ativo; um índice de assinante não é identidade verificada; um contador precisa de contexto de descontinuidade antes que sua variação seja interpretada; uma notificação não prova entrega de pacote. A NATV2-MIB pode melhorar a coerência da observação sem unir configuração, estado, encaminhamento, identidade e resultado da aplicação em uma só afirmação.

A lição histórica é concreta: um padrão de gestão pode tornar-se prescritivo demais quando transforma controles próprios de cada implementação em uma interface comum. A RFC 7658 não respondeu acrescentando colunas à tabela de interfaces. Reavaliou a unidade modelada. A MIB seguinte tornou menos configurações universais e mais contexto lógico observável. A questão deixou de ser apenas “qual interface possui este mapa?” e passou a ser “qual instância, domínio, assinante, pool e estado esta observação descreve?”.

Fontes