Resumen
- RFC 5309 permite tratar un LAN de dos routers como circuito punto a punto y eliminar DR/DIS y pseudonodo, pero mantiene la encapsulación multicast y el identificador de VLAN del medio.
- La coincidencia de configuración es obligatoria y no hay fallback. Incluso con adyacencia, el tráfico unicast depende de next hop IP y de una asociación MAC obtenida por ARP, ND, configuración o aprendizaje.
Un cambio de modelo, no de materia
Un segmento broadcast se representa normalmente como una red compartida. El protocolo elige un DR o DIS y anuncia una entidad virtual. Si sólo hay dos routers, esa maquinaria puede resultar innecesaria. RFC 5309 propone configurar el tipo de circuito como punto a punto aunque el soporte sea Ethernet.
El IGP deja de representar el segmento como pseudonodo y anuncia la relación directa. Sin embargo, la trama conserva cabecera MAC. Los paquetes de control IS-IS siguen siendo LAN desde la capa de enlace y AllISs es la dirección recomendada. En un entorno VLAN, una etiqueta equivocada impide la entrega aunque ambos routers calculen el mismo modelo lógico.
La configuración afirma que sólo hay dos participantes relevantes; no mide el cable ni inventaría todos los puertos. La exclusividad física o lógica necesita evidencia del conmutador.
La incompatibilidad se descarta
Si una interfaz punto a punto recibe Hello de LAN, debe descartarlo. Si una interfaz LAN recibe Hello punto a punto, también. Una identidad distinta del vecino establecido produce otro descarte. Ambos extremos deben soportar la técnica y configurarla igual.
El desacuerdo no negocia un modo común. La vecindad nunca se forma y la única salida es corregir manualmente la configuración. Esta ausencia de fallback evita que una intención errónea quede oculta por una compatibilidad automática.
Una automatización debe tratar el cambio como pareja: intención en ambos lados, ventana, contadores de descarte, identidad esperada y rollback simétrico. Una sola orden exitosa no es el resultado.
El next hop vuelve por la capa dos
En una interfaz punto a punto tradicional, no hace falta elegir next hop sobre el medio. En p2p-over-LAN sí: una trama Ethernet unicast necesita MAC de destino. RFC 5309 exige una dirección IP válida del vecino para resolverla.
Con IPv4 unnumbered, ARP resuelve una dirección interna prestada. Puede ser necesario relajar el control que exige que la fuente ARP pertenezca a la subred local. Con IPv6, ND resuelve la dirección link-local. También se puede configurar la MAC o aprenderla de la trama del protocolo de routing.
Este último método muestra la separación con nitidez. El router vio una trama de control y extrajo su MAC. Todavía debe conservar la asociación, instalar la recursión y emitir el paquete por el VLAN correcto. Aprender no equivale a reenviar; reenviar no equivale a entregar.
La dirección ahorrada se convierte en telemetría pendiente
Unnumbered economiza direcciones y configuración. También elimina la dirección específica que permitía probar una interfaz. La operación debe sustituirla con estado de puerto/VLAN, identidad del vecino, tabla ARP/ND, origen de la MAC, FIB, contadores y sondas bidireccionales.
Dividir una red multiacceso en muchos VLAN de dos routers también cambia el coste del sistema. Cada relación es sencilla, pero crecen la base de enlaces, el flooding y el cálculo. La claridad local puede reducir la eficiencia agregada.
Alcance
RFC 5309 es Informational y no una norma de Internet. No certifica implementaciones actuales, exclusividad de VLAN ni interoperabilidad de mecanismos propietarios. RFC 5303 trata la reciprocidad de una adyacencia; no crea una asociación MAC. RFC 5304 autentica mensajes y RFC 5305 anuncia atributos, pero ninguna de esas pruebas observa un paquete de aplicación.
Para demostrar funcionamiento hacen falta configuraciones, Hellos, IDs, pertenencia VLAN, adyacencia, next hop, ARP/ND o mapping, ruta/FIB y tráfico capturado. El nombre «punto a punto» no cancela esa cadena.
Fuentes
- RFC 5309: operación punto a punto sobre LAN
- RFC 5309 en texto plano
- Información RFC Editor
- RFC 5309 en Datatracker
- Historial de RFC 5309
- Referencias de RFC 5309
- Documentos que citan RFC 5309
- Erratas de RFC 5309
- RFC 1195: IS-IS para IP
- RFC 2328: OSPF versión 2
- RFC 5340: OSPF para IPv6
- RFC 5303: saludo IS-IS de tres vías
- RFC 5304: autenticación IS-IS
- RFC 5305: extensiones TE de IS-IS
- RFC 5308: routing IPv6 con IS-IS
- RFC 8174: palabras normativas
- Registro IANA de TLV IS-IS
- Heng Lu: On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
- Heng Lu: Running Code Primary
- Heng Lu: On the Agency Problem at the Core of Internet Governance
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance
