Resumen

  • La RFC 4008 organizó la gestión de NAT alrededor de interfaces, categorías de servicio y parámetros configurables; la RFC 7658 explica por qué ese modelo no se ajustaba a muchas implementaciones.
  • NATV2-MIB redujo la configuración común y amplió la observación de instancias lógicas, ámbitos de direcciones, abonados, grupos de direcciones y estado.

Una interfaz como punto de partida

El procedimiento de configuración que muestra la RFC 4008 comienza creando una entrada en natInterfaceTable. El gestor necesita conocer un ifIndex y asignar a esa interfaz un ámbito privado o público. Después añade mapas de direcciones con el mismo índice y configura tiempos de espera. Así, el primer elemento del esquema no es la regla de traducción: es el borde físico que ordena las reglas y buena parte del estado.

La decisión parecía razonable. Los paquetes atraviesan interfaces; un administrador puede asociarlas con ámbitos de direccionamiento; y una MIB puede enlazar las reglas configuradas con las vinculaciones y sesiones que se derivan de ellas. RFC 4008 definió tablas de interfaces, mapas, vínculos de dirección o de dirección y puerto, y sesiones que relacionaban la vista privada con la pública. También pretendía servir tanto para configurar como para supervisar un dispositivo NAT. RFC 4008, secciones 1 y 4

El problema no era que el modelo careciera de detalle. Era que convertía una forma concreta de organizar un dispositivo en el centro de una interfaz común. Una traducción podía pertenecer a un servicio lógico distribuido entre varias interfaces; una implementación podía no conservar el vínculo único que requería la tabla. El punto de partida útil para un producto no tenía por qué ser la unidad adecuada para describir todos los productos.

La retrospectiva de RFC 7658

La RFC 7658 enumera con franqueza por qué se marcaron como obsoletos los objetos de RFC 4008. Según el documento, los algoritmos y estructuras de datos de NAT variaban mucho entre implementaciones. Eso producía parámetros de configuración incompatibles y pocas implementaciones podían afirmar conformidad completa. Incluso la exposición de solo lectura de parámetros como los tiempos de espera dificultaba la conformidad básica. La lección declarada es que la MIB debería ser de solo lectura en la medida de lo posible y no utilizarse para publicar la configuración del NAT. RFC 7658, sección 3

La dependencia de interfaces era un desacuerdo de arquitectura. RFC 7658 dice que muchos NAT no seguían la interfaz asociada a una traducción o vinculaban un mapa con un conjunto de interfaces. Pero en RFC 4008 ifIndex daba forma a las tablas de interfaz, mapas, vínculos y sesiones. Si el modelo interno del equipo no mantenía esa relación, no podía representar limpiamente lo que la norma esperaba. La conclusión de los autores fue que NAT es una función lógica que puede ser independiente de las interfaces.

Las categorías de servicio y la lista de protocolos mostraban límites parecidos. RFC 4008 usaba basicNat, napt, bidirectionalNat y twiceNat; RFC 7658 las considera mal definidas porque las implementaciones podían emplear otras categorías o ninguna. No son las categorías de NAT en cono de RFC 3489, sino las etiquetas de servicio de la MIB de 2005. El sucesor se apoya en el vocabulario de comportamientos de NAT de RFC 4787. Para protocolos, la enumeración other, ICMP, UDP y TCP asignaba números propios que no correspondían a los números de protocolo estándar, lo que limitaba la representación de opciones como DCCP y SCTP. NATV2-MIB usa números del registro de la IANA.

Retirar un modelo y definir otro

La transición de 2015 separó la deprecación del reemplazo. RFC 7658 conserva las definiciones de RFC 4008 pero cambia el estado de los objetos a deprecated. RFC 7659 especifica NATV2-MIB. Los identificadores antiguos no se reinterpretan en silencio como si nada hubiera cambiado. RFC 7658 RFC 7659

NATV2-MIB se concibió principalmente para supervisar. La configuración de solo lectura se limita a lo necesario para entender el estado y las estadísticas. Se quita la configuración escribible, salvo los controles de generación de notificaciones y las cuotas de recursos NAT. No desaparece todo control: siguen existiendo límites protectores. Lo que desaparece es la pretensión de que una sola MIB configure de manera uniforme motores NAT muy distintos.

El modelo se organiza alrededor de instancias lógicas. Los mapas dejan de estar definidos por una interfaz como eje principal. La MIB puede representar varias instancias NAT en un equipo, un número arbitrario de ámbitos de direcciones, abonados, grupos de direcciones, protocolos, estado, estadísticas y notificaciones. Esas dimensiones son relevantes para CGN, donde muchos abonados comparten direcciones y puertos y donde cada instancia puede tener un presupuesto de recursos distinto.

RFC 7659 también revisa la indexación de mapas de puertos para facilitar el recorrido desde parámetros visibles en un paquete externo hasta el extremo interno correspondiente. Es una ayuda de gestión y búsqueda. No prueba por sí sola quién originó el tráfico, que un paquete llegara a destino ni que una aplicación funcionara. RFC 7659, secciones 2 y 3

RFC 6888 aporta el contexto operativo de los recursos compartidos: un CGN puede tener abonados que compiten por puertos y memoria de estado, y recomienda límites por abonado para moderar consumos excesivos. NATV2-MIB ofrece objetos para representar parte de esos límites y observar sus efectos. Los RFC no muestran qué proveedores aplicaron los objetos, qué umbrales eligieron ni cuál fue el resultado de una política concreta. RFC 6888, secciones 4 y 5

Qué demuestra la historia de la MIB

Este cambio fue una corrección de abstracción. RFC 4008 intentó hacer configurable NAT mediante una jerarquía portable de tablas. RFC 7658 dejó constancia de que la interfaz no era un punto común en muchas implementaciones, que los parámetros de configuración variaban demasiado y que algunas categorías y listas cerradas no representaban bien el espacio real. RFC 7659 redujo la superficie de escritura compartida y amplió la descripción del estado lógico.

La conclusión debe mantenerse acotada: el modelo de gestión tuvo que cambiar para poder describir más tipos de implementación. Eso no demuestra que todos los fabricantes adoptaran NATV2-MIB, que se convirtiera en un estándar operativo universal ni que mejorara el rendimiento de la traducción. RFC 7659 dice que la antigua MIB se implementó poco, pero no ofrece una tasa y tampoco mide la adopción de la nueva.

La frontera con los cortafuegos también es explícita. RFC 4008 y RFC 7658 dicen que estas MIB no cubren las funciones de firewall y no se deben usar para configurarlas o supervisarlas. Una fila de traducción no sustituye una regla de filtrado.

Tampoco un objeto de gestión equivale a un resultado de servicio. Un grupo configurado no es un mapa activo; un índice de abonado no es una identidad verificada; un contador requiere conocer sus discontinuidades antes de calcular una diferencia; ninguna de esas señales demuestra que el paquete llegara o que el usuario recibiera el servicio. NATV2-MIB puede ordenar mejor la vista de gestión sin fusionar configuración, estado, tratamiento del paquete e impacto en la aplicación.

La lección histórica es concreta: una norma de gestión puede excederse cuando convierte en interfaz común controles propios de cada implementación. RFC 7658 no respondió añadiendo todavía más campos de interfaz; cuestionó la unidad que se estaba modelando. La MIB posterior hizo menos universal la configuración y más visible el contexto de cada instancia. La pregunta dejó de ser solo «¿qué interfaz posee este mapa?» y pasó a ser «¿qué función NAT, ámbito, abonado, grupo de direcciones y estado describe esta observación?»

Fuentes