Resumen
- RFC 3021 permitió que los dos valores de un prefijo IPv4
/31fueran direcciones de host cuando se aplicaban a un enlace genuinamente punto a punto. - La máscara reducía el consumo de cuatro direcciones a dos, pero no demostraba que el medio tuviera solo dos participantes ni que ambos equipos compartieran la nueva interpretación.
La avería más instructiva no necesitaba un cable roto. Bastaba con que un router entendiera RFC 3021 y el otro conservara la regla anterior. Para el primero, el valor con el bit de host en uno era la dirección del vecino. Para el segundo, podía seguir pareciendo la forma reservada para broadcast dirigido. El mismo patrón binario llegaba a dos programas con significados distintos.
Ese borde operativo explica mejor el documento que la cifra /31. En una subred convencional /30, cuatro valores financiaban dos interfaces: uno quedaba como número de red y otro como broadcast. En un enlace punto a punto solo podían existir dos extremos y cualquier paquete emitido por uno llegaba al otro. Reservar dos de cuatro valores no añadía capacidad funcional.
RFC 3021 dejó un solo bit de host. Sus dos resultados—cero y uno—debían interpretarse como hosts en ese contexto. Cada enlace numerado consumía dos direcciones en vez de cuatro. La norma calculó que 500 enlaces recuperarían 1.000 direcciones.
La excepción dependía de una realidad externa al prefijo
El ahorro no residía únicamente en el sistema de numeración. Dependía de que la interfaz fuera punto a punto. El RFC excluyó expresamente otros tipos de enlace de su análisis. Una máscara de 31 bits aplicada a un segmento compartido no probaba que hubiera solo dos participantes; solo afirmaba una interpretación que podía ser falsa para el medio real.
También dependía de las dos implementaciones. El texto advirtió que un enlace en el que solo un extremo admitiera prefijos de 31 bits podía no funcionar correctamente. Por eso, una configuración aceptada era evidencia de intención, no de acuerdo bilateral.
La distinción importa al reconstruir incidentes. Ver /31 en dos copias de configuración no responde qué versión estaba ejecutándose, qué camino clasificó la dirección, si un filtro la descartó ni si el tráfico llegó. Esos hechos pertenecen a capas diferentes.
Al ocupar ambos valores, desaparecía el broadcast dirigido
No quedaba una tercera dirección que pudiera reservarse para broadcast dirigido. RFC 3021 eliminó esa operación en el enlace y mantuvo el broadcast limitado para el tráfico que lo necesitara. Los routers remotos seguían encaminando de forma classless; el dispositivo directamente conectado aplicaba la excepción y entregaba cada valor a su extremo.
La ausencia de broadcast dirigido reducía una superficie empleada por ataques de amplificación tipo smurf. RFC 2644 ya había cambiado el comportamiento predeterminado de los routers frente a ese tráfico. El efecto de RFC 3021 era específico: menos enlaces físicos podían actuar como destino de esa modalidad de réplica. No autenticaba al vecino, no protegía OSPF o BGP y no certificaba disponibilidad.
Las reglas antiguas seguían vigentes fuera del caso estrecho
RFC 950 había descrito el problema de un campo de host de un bit: sus dos combinaciones ya tenían significados especiales. RFC 1122 y RFC 1812 definían cómo hosts y routers trataban las formas de todos ceros y todos unos. RFC 3021 añadió excepciones explícitas para origen, recepción y entrega cuando la dirección pertenecía a un extremo punto a punto con máscara de 31 bits.
Fuera de ese caso, continuaban los comportamientos de descarte o broadcast. No se abolió el concepto de dirección de red ni el de broadcast. La semántica se hizo condicional a la forma del enlace.
El plano de control no cerraba el plano de entrega
El documento informó de código beta en varios fabricantes y pruebas positivas de al menos tres ISP con OSPF, IS-IS, BGP y EIGRP. Era evidencia histórica de viabilidad, no un censo de adopción ni una garantía sobre productos sin nombre.
Una vecindad estable demuestra que cierto intercambio de control alcanzó al par. No prueba que ambos valores respondan a gestión, que todas las listas de control los acepten, que los caminos de datos sean simétricos ni que una aplicación haya recibido la carga útil. Una ruta puede estar presente mientras una herramienta todavía rechaza la supuesta dirección de red.
Fuentes
- Registro de RFC Editor para RFC 3021
- RFC 3021 en HTML
- RFC 3021 en texto
- Registro de RFC Editor para RFC 950
- RFC 950 en HTML
- Registro de RFC Editor para RFC 1122
- RFC 1122 en HTML
- Registro de RFC Editor para RFC 1812
- RFC 1812 en HTML
- Registro de RFC Editor para RFC 2644
- RFC 2644 en HTML
- Registro de RFC Editor para RFC 6164
- RFC 6164 en HTML
- Lu Heng sobre la primacía del código en ejecución
- Lu Heng sobre la especificación inicial mínima
- Lu Heng sobre las capas de realidad
Lu Heng no redactó ni avaló RFC 3021. Sus textos se usan como lentes analíticas declaradas.
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
