Resumen

  • RFC 4012 conservó import, export y default en el marco de unicast IPv4 y añadió atributos mp-* con alcance por familia.
  • En los nuevos atributos, omitir la cláusula AFI significa any para unicast y multicast de IPv4 e IPv6; no significa “ninguna familia”.

Un AFI ausente no era un campo vacío

Al leer un mp-import sin cláusula afi, cabría pensar que la familia no está indicada. RFC 4012 resuelve esa omisión de otra manera: significa any, un alcance definido que comprende IPv4 unicast, IPv4 multicast, IPv6 unicast e IPv6 multicast. Falta una palabra en la línea, pero no falta una regla. La interpretación no queda a criterio de cada lector o analizador.

Ese valor por defecto se aplica a los atributos nuevos mp-*. Los antiguos import, export y default mantienen su significado de unicast IPv4. Así, RFC 4012 evita que los registros heredados cambien de sentido sin aviso y que las nuevas expresiones multiprotocolo queden semánticamente vacías. Antes de leer quién acepta qué, conviene preguntar qué alcance asigna la gramática cuando no aparece afi.

En 1999, el lenguaje era de unicast IPv4

RFC 2622 definió RPSL para describir políticas de enrutamiento unicast IPv4. Sus atributos import, export y default se entienden dentro de ese alcance. En marzo de 2005, RFC 4012 incorporó IPv6 y multicast procurando mantener la compatibilidad con las expresiones existentes. RFC 2622 RFC 4012

Por eso no cambió el sentido de los atributos antiguos: continuaron vinculados a unicast IPv4. Para los casos multiprotocolo aparecieron mp-import, mp-export y mp-default. La cláusula afi permite especificar ipv4.unicast, ipv4.multicast, ipv6.unicast o ipv6.multicast, entre otros ámbitos. Si se omite la cláusula opcional en un atributo mp-*, RFC 4012 le asigna el alcance any, es decir, las cuatro familias descritas. Es una regla de lectura de RPSL, no la garantía de que el equipo implemente o use todas ellas. RFC 4012, secciones 2.1–2.5

Esta distinción evita atribuirle a la norma una universalidad que no reclama. El lenguaje puede representar que una política solo concierne a IPv6 unicast, o que tiene una amplitud mayor. Cada red sigue tomando sus propias decisiones de soporte, filtros y anuncios por familia.

El diccionario también compone alcances: ipv4 e ipv6 abarcan el unicast y el multicast de cada versión; any.unicast y any.multicast agrupan un tipo de tráfico en ambas; any reúne las cuatro combinaciones básicas. La sintaxis es breve porque esas uniones tienen nombre, no porque su alcance sea implícito.

La misma sigla AFI, en capas distintas

RFC 4012 también añade la clase route6, pero la clave de ese objeto y la autorización de cambios son asuntos distintos de la cláusula AFI opcional; RFC 2725 trata esa autorización. Aquí solo marca un límite, no abre un segundo tema. RFC 4012, sección 3 RFC 2725

BGP también usa AFI/SAFI, pero RFC 4760 los aplica al alcance de la alcanzabilidad de red y del siguiente salto en los mensajes UPDATE. La AFI opcional de RFC 4012 delimita una expresión de política RPSL. Compartir siglas no vuelve intercambiables esas declaraciones: la selección y los anuncios por vecino pertenecen al funcionamiento de BGP descrito por RFC 4271. RFC 4271 RFC 4760

Las uniones con nombre hicieron componible la gramática

Decir que RPSL añadió IPv6 es cierto, pero incompleto. RFC 4012 hizo explícito el alcance por familia y nombró las uniones entre versiones y tipos de tráfico. Esa precisión describe el lenguaje; no afirma que las redes trataran ambas versiones igual.

Ese detalle importa en redes duales. Los vecinos, filtros, siguientes saltos y decisiones pueden variar entre IPv4 e IPv6. Una regla con afi ipv6.unicast no equivale a otra que cubra any. Sin embargo, escribir la diferencia no decide por sí solo qué política adopta el sistema autónomo.

RFC 8212, de 2017, ofrece un punto cronológico posterior: exige políticas explícitas para EBGP, pero regula el comportamiento de BGP y no cambia cómo RFC 4012 interpreta una AFI omitida en RPSL. RFC 8212

Las Notas 65 y 64 de Lu Heng aportan aquí una lente editorial, no una intención atribuida a los autores de la norma: los sistemas comunes deben guardar relación con las necesidades de interoperabilidad, y los cambios adquieren efecto mediante su adopción en sistemas que funcionan. Desde esa perspectiva, RPSLng vale porque hace comparables las descripciones; el equipo ejecutor conserva el punto de decisión sobre qué cargar y anunciar. Nota 65 Nota 64

Los documentos no ofrecen una tasa de adopción, un censo de objetos completos ni datos sobre el despliegue actual de IPv6 en operadores. La conclusión respaldada es más acotada: RFC 4012 hizo más precisa y determinista la expresión del alcance de una política en RPSL.

Fuentes primarias