Resumen

  • Una máscara DHCPv4 /32 y la omisión de la opción de router pueden atender a un cliente antiguo y quitarle su ruta IPv4 normal hacia fuera del enlace.
  • Las solicitudes repetidas pueden cesar, pero el cliente mantiene una concesión única y todavía puede recibir paquetes desde su enlace.

Callar una solicitud no devuelve la dirección al pool

Un equipo antiguo de doble pila puede seguir pidiendo IPv4 aunque el operador quiera que sus aplicaciones usen IPv6. Dejar de responder quizá solo provoque más solicitudes DHCPv4 sin respuesta. El blog técnico de LACNIC del 2 de octubre presenta una salida acotada, tomada de un Internet-Draft individual: contestar con campos DHCPv4 conocidos y configurar la interfaz sin una ruta IPv4 normal hacia destinos fuera del enlace.

La opción 1 de DHCPv4 entrega la máscara 255.255.255.255, o /32. El servidor no envía la opción 3, que anunciaría un router. Con /32, los demás destinos IPv4 quedan fuera del enlace; sin un router anunciado, el host no tiene siguiente salto. Recibe la configuración que pidió y puede dejar de repetir la búsqueda, pero no gana una ruta IPv4 funcional hacia fuera.

Esto no desactiva completamente IPv4. La interfaz conserva una dirección y sigue usando DHCPv4. El dispositivo puede tener otras interfaces, rutas estáticas, túneles o aplicaciones con otro comportamiento. Una aplicación podría reintentar por IPv6 tras fallar IPv4, pero el borrador describe una expectativa, no una garantía para todos los sistemas y servicios.

La concesión única sigue en el registro

El borrador señala un costo fácil de pasar por alto: el servidor DHCPv4 todavía debe entregar una dirección única a cada host del mismo enlace. No se puede asignar normalmente la misma dirección a todos los clientes silenciosos de un segmento compartido. La detección de conflictos puede sondear una dirección antes de usarla; si dos clientes la reciben, el conflicto puede aparecer. La repetición del mismo domicilio en conflicto puede producir un ciclo de DHCPDECLINE.

Así, el volumen de solicitudes puede caer mientras la asignación continúa. La concesión ocupa una entrada del pool hasta que el cliente libera la dirección o vence el plazo dinámico. RFC 2131 define la asignación dinámica como temporal y reutilizable cuando deja de ser necesaria. Una concesión activa no mide tráfico ni demuestra que la dirección volvió a estar disponible.

El efecto económico depende del pool. Si se asigna IPv4 pública escasa, la concesión activa conserva un costo de oportunidad aunque el host no pueda usarla para llegar por la ruta habitual a destinos IPv4 remotos. El borrador también contempla pools link-local o RFC1918. Un pool privado dedicado puede proteger capacidad pública, pero todavía necesita domicilios únicos, estado de servidor, gestión de conflictos y control de solapamientos con la red privada existente.

El texto permite reutilizar cuidadosamente un pool entre enlaces físicos diferentes cuando el servidor DHCP está conectado directamente a cada enlace. No es una regla general. Con DHCP relay, el servidor usa la dirección del relé para elegir el pool, por lo que el borrador exige unicidad en toda la red retransmitida. Ignorar ese límite puede convertir un ahorro aparente en un error de asignación.

Un plazo largo reduce renovaciones y prolonga la reserva

El borrador plantea concesiones de un día o varias semanas porque estos hosts no deberían alcanzar destinos externos por IPv4 y un pool local o privado puede ser amplio. Un plazo mayor reduce renovaciones y trabajo del servidor, pero mantiene la dirección reservada por más tiempo. En un pool público escaso, menos mensajes DHCP no significan automáticamente más domicilios libres. Conviene medir solicitudes y días de ocupación juntos. Es una deducción operativa del modelo de concesión, no un resultado medido por el blog.

La opción 108 ofrece otro camino para otra clase de cliente. RFC 8925 normaliza IPv6-Only Preferred para clientes compatibles en una red IPv6-mostly configurada expresamente. Si cliente y servidor lo admiten, el cliente puede prescindir de una dirección IPv4 cuando la red ofrece la funcionalidad necesaria. Esto puede preservar el pool. El método /32 apunta a clientes que no entienden la opción 108; el borrador dice que ambos mecanismos pueden coexistir. Ninguno prueba que las aplicaciones, DNS64/NAT64 o servicios requeridos funcionen.

Sin puerta de enlace no significa sin firewall

Omitir la opción de router quita la ruta habitual hacia destinos IPv4 fuera del enlace, pero no vuelve invisible la interfaz. La sección de seguridad del borrador dice que otro host del enlace aún puede enviar paquetes IPv4 al equipo con máscara /32. Recomienda un firewall local que permita en esa interfaz solo DHCPv4 entre cliente y servidor o relé.

“No puede iniciar una conexión IPv4 enrutada hacia fuera” y “no puede recibir paquetes IPv4” son afirmaciones distintas. La primera se desprende de la configuración propuesta; la segunda no. Se necesita una política de entrada explícita si quedan servicios locales activos o si el dispositivo es alcanzable por otra interfaz.

Qué muestran las fuentes públicas

El blog de LACNIC dice que su autor, Alejandro Acosta, probó la técnica en Windows 11, Fedora 43, Raspberry Pi OS basado en Debian Trixie, Chromecast y Google Nest. También aclara que no probó teléfonos inteligentes y pide más pruebas de compatibilidad. Son ensayos reportados por el autor, no una replicación independiente, muestra representativa ni evidencia de despliegue productivo. El blog añade que las opiniones de sus autores no necesariamente reflejan las de LACNIC.

El documento citado es la versión 02 de un Internet-Draft individual. IETF Datatracker lo registra como expirado el 15 de junio de 2026 y sin estatus formal en el proceso de estándares de IETF. La expiración no prueba un rechazo técnico; la existencia del borrador tampoco lo convierte en norma aprobada. Las fuentes revisadas no publican una reducción medida de broadcasts DHCP, una serie de ocupación del pool, resultados de fallback de aplicaciones ni auditoría de seguridad entrante.

Quien pruebe el método debería publicar por separado las solicitudes repetidas por cohorte, concesiones activas y días de dirección por pool público, privado y link-local, liberaciones, vencimientos y DHCPDECLINE, límites de relay y enlace, éxito de aplicaciones IPv6 en una muestra y reglas de filtrado entrante. Silenciar la red, recuperar direcciones escasas, mantener aplicaciones y controlar exposición son resultados distintos.

Fuentes: