Menos de 30 de los aproximadamente 25 millones de servidores de nombres con sede en el Reino Unido tenían direcciones IPv6 cuando se publicó el informe sobre el despliegue de IPv6 del gobierno del Reino Unido en 2010. Ese punto de partida histórico ayuda a explicar por qué tantos planes de direccionamiento, procedimientos de soporte y registros de activos se crearon en torno a IPv4.
Gestionar direcciones IP ahora significa mantener un entorno donde los dispositivos pueden utilizar cualquiera de los dos protocolos, a veces sin que los administradores se den cuenta. La disciplina clave es un propietario responsable, una intención de enrutamiento documentada y un registro de asignación rastreable para cada dirección. Las rutas redundantes están bien; la propiedad contradictoria y la alcanzabilidad no explicada, no.
Cuándo utilizar direcciones reservadas o estáticas por DHCP
En agosto de 2026, el 54.27% de los 5,340,321 hosts rastreados utilizaban pila doble, mientras que el 45.73% permanecía únicamente con IPv4, según las mediciones del Reino Unido de la Internet Society. Estas son mediciones de hosts rastreados, no un censo de dispositivos corporativos, pero ilustran por qué un inventario exclusivo de IPv4 ya no describe todo lo que un equipo de red puede encontrar.
Un dispositivo puede comunicarse a través de IPv6 mientras que su registro de soporte, objeto de firewall y hoja de trabajo de incidentes aún contienen solo IPv4. Trate la doble pila como un segundo conjunto de registros, incluida la historia de direcciones, en lugar de como una simple capacidad de enrutamiento.
Elija un método de asignación por clase de dispositivo antes de diseñar las subredes. DHCP emite asignaciones de direcciones con límite de tiempo; una reserva proporciona a un dispositivo concreto una dirección predecible a través de ese mismo servicio. El glosario de DHCP ofrece una referencia útil a la hora de explicar esa distinción a colegas fuera del área de redes.
Métodos de asignación de direcciones y cuándo utilizarlos
| Método | Uso recomendado | Estabilidad | Riesgo principal |
|---|---|---|---|
| DHCP dinámico | Invitados, contratistas, clientes de estancia corta | Normalmente se mantiene mediante renovaciones; apta para reutilización tras caducar | La reutilización oculta quién tenía la dirección si no hay registros |
| Reserva DHCP | Impresoras, puntos de acceso, cámaras, IoT | Dirección fija asignada igualmente por DHCP | Reserva obsoleta cuando el dispositivo deja de utilizarse |
| Configuración estática | Routers, firewalls, DNS, gestión fuera de banda | Permanente hasta que se cambie manualmente | Dirección huérfana sin registro de propietario |
| SLAAC | Clientes IPv6 habituales en una /64 | Las direcciones estables pueden coexistir con direcciones privadas rotativas | Host invisible si IPAM nunca lo detecta |
| DHCPv6 | Clientes IPv6 compatibles que requieren registros de asignación en el servidor | Concesión con registro en el servidor | Desviación del ámbito si el DNS no se actualiza con la concesión |
Adapte las concesiones al comportamiento de los dispositivos
Una concesión no fuerza un cambio de dirección en cada renovación. Los clientes suelen renovar la dirección que ya tienen, por lo que no utilice la rotación de DHCP como un control de seguridad.
Para un establecimiento hipotético, una concesión de invitado de ocho horas podría adaptarse a los visitantes diurnos, mientras que una LAN de personal podría comenzar con concesiones de uno a siete días. Estos son puntos de partida para la configuración, no umbrales de cumplimiento. Compare la ocupación del pool, el tráfico de renovación y los patrones de visita antes de ajustarlos.
Utilice reservas para el equipamiento que necesite un direccionamiento estable pero que deba seguir siendo revocable de forma centralizada. Mantenga las direcciones configuradas manualmente fuera de los pools dinámicos y registre al administrador responsable de cambiarlas. La configuración estática es lo más recomendable para la infraestructura que debe iniciarse o seguir siendo gestionable sin DHCP.
En IPv6, SLAAC permite a los clientes construir direcciones a partir de un prefijo anunciado. DHCPv6 puede proporcionar registros de asignación cuando los clientes lo admiten, pero no reemplaza los anuncios de router para el descubrimiento del router predeterminado y no identifica automáticamente a una persona.
Regla de asignación: Asigne a cada clase de dispositivo un método predeterminado y, a continuación, documente las excepciones con un propietario y una razón.
Etiquete cada VLAN actual con el método elegido. Una VLAN de uso mixto puede necesitar clases documentadas independientes, en lugar de una regla artificial que exija que todos los dispositivos se comporten de forma idéntica.
Cómo dimensionar subredes y dejar espacio para crecer
Dimensione el espacio para los dispositivos que se pueden conectar simultáneamente, incluidos los reemplazos, clientes temporales y la infraestructura. No elija un prefijo simplemente porque otra ubicación lo haya utilizado.
Tamaños de prefijo predeterminados por zona de red
Estos son puntos de partida de ingeniería. Valide la demanda de hosts, las reservas de la nube y la compatibilidad de la plataforma antes de adoptar una fila.
| Zona | Plan IPv4 | Plan IPv6 | Nota de planificación |
|---|---|---|---|
| LAN de empleados o usuarios | /23 o /24 | /64 | Deje libre el siguiente bloque antes de que la VLAN se llene |
| WiFi de invitados | /22 para un recinto con mucho tráfico | /64 | Concesiones cortas y sin ruta hacia empleados o servidores |
| Servidores e infraestructura | /24 o más pequeño, en su mayoría estático | /64 | Cada host gestionado identificado en el DNS directo e inverso |
| Gestión y fuera de banda (OOB) | /26 o /27 | /64 | Sin enrutamiento hacia invitados ni exposición directa a Internet |
| Enlace punto a punto | /31 | /127 | Utilícelo únicamente donde ambos extremos lo admitan |
| Agregado por sitio | Un bloque resumible por sitio | A menudo un /48 por sitio | Anuncie el resumen, no cada VLAN |
| VPC o VNet en la nube | Espacio RFC1918 sin solapamientos | Asignación IPv6 del proveedor | Verifique el solapamiento antes de cada fusión o emparejamiento (peering) |
Utilice una calculadora de subredes para comprobar los límites y la capacidad en lugar de hacer aritmética de prefijos de memoria. Para las LAN IPv4 ordinarias, distinga las direcciones totales de las direcciones de host asignables; las plataformas en la nube pueden reservar direcciones adicionales.
Para IPv6, la guía de direccionamiento del NHS England especifica direcciones de 128 bits y un tamaño de subred estándar de 64 bits. Utilice /64 para LAN normales y segmentos de seguridad, no subnets de cliente más pequeñas destinadas a conservar espacio de direcciones.
Cree la jerarquía antes de completarla
Asigne a cada sitio un bloque de resumen IPv4 alineado. Cuando la asignación lo permita, asígnele también un agregado IPv6 y, a continuación, divida los prefijos de VLAN dentro de esos límites.
Reserve un bloque de crecimiento adyacente y correctamente alineado para las redes de usuarios. La adyacencia por sí sola no garantiza que dos prefijos puedan convertirse en un prefijo más grande, así que compruebe el límite binario antes de prometer una expansión sin problemas.
El espacio de direcciones privadas no es único a nivel global. Las oficinas, las empresas adquiridas y los proyectos en la nube pueden elegir de forma independiente rangos superpuestos y descubrir el conflicto solo cuando alguien solicita un emparejamiento (peering).
Un esquema de un solo sitio puede seguir siendo legible sin enumerar direcciones individuales:
| Rol de la VLAN | Prefijo asignado | Bloque primario | Reserva de crecimiento |
|---|---|---|---|
| Personal | /24 | Resumen IPv4 del sitio | /24 adyacente alineado |
| Invitado | /22 | Resumen IPv4 del sitio | /22 independiente alineado |
| Gestión | /27 | Resumen IPv4 del sitio | /27 adyacente alineado |
| Segmentos de cliente IPv6 | /64 cada uno | Agregado IPv6 del sitio | Prefijos de segmento no asignados |
Un resumen es una ventaja de enrutamiento, no un permiso para que todas las zonas se comuniquen. Mantenga explícitos los límites de las directivas para invitados, gestión y servidores.
Cómo crear un inventario de direcciones con control de versiones
Un inventario de direcciones solo es útil si refleja tanto las asignaciones planificadas como la configuración en tiempo real. La gestión de direcciones IP (IPAM) registra quién es el propietario de cada prefijo, qué admite y dónde aparece su información de dirección. Mantenga un propietario, una ruta prevista y un registro rastreable para cada dirección.
Registre el prefijo, propietario, propósito comercial, sitio, zona de seguridad, método de asignación y fecha de revisión. Incluya las fechas de caducidad para las asignaciones temporales, además de las referencias de registro y enrutamiento para los bloques públicos. Aplique control de versiones al inventario para que cada cambio cuente con una aprobación y un diff significativo.
Concilie la configuración en un orden repetible
- Registros del registro. Confirme las asignaciones públicas que la organización tiene derecho a utilizar.
- Zonas DNS. Exporte registros directos e inversos, incluidos los registros A y AAAA obsoletos.
- Registros DHCP. Recopile concesiones, reservas, exclusiones y asignaciones DHCPv6.
- Objetos de firewall y NAT. Registre direcciones traducidas, servicios publicados y reglas de gestión.
- Redes cloud. Exporte asignaciones de VPC, VNet y subredes en las cuentas o suscripciones correspondientes.
- Estado de enrutamiento. Compare los anuncios configurados con las rutas aprendidas e instaladas.
La exportación más reciente no es automáticamente fidedigna. Una subred en la nube no documentada puede ser legítima; un objeto de firewall antiguo puede exponer un servicio sin propietario actual. Asigne cada discrepancia a alguien que pueda establecer su propósito.
Utilice estados claros del ciclo de vida como asignado, reservado, activo, en desuso y expuesto externamente. Trate la exposición como un indicador independiente: una subred activa también puede estar expuesta externamente.
Verifique lo que parece vacío
Compruebe cada rango de direcciones que la organización posea o esté autorizada a evaluar, incluidos los rangos que no se crea que estén en uso. Esto ayuda a descubrir asignaciones y servicios olvidados sin extender las comprobaciones más allá de los límites aprobados. La guía de conectividad segura sobre segregación de redes OT del National Cyber Security Centre se refiere a la separación de redes de tecnología operativa; no indica a las organizaciones que escaneen el espacio de direcciones públicas.
Confirme los registros con las fuentes que ya estén dentro de su alcance autorizado, como zonas DNS, configuraciones de red en la nube, registros de enrutamiento e información de vecinos. Para equipos sensibles o de tecnología operativa (OT), siga los procedimientos de evaluación aprobados por la organización.
Documente el límite que representa cada VLAN, incluidos sus prefijos y rutas permitidas. Para entornos del sector público del Reino Unido, registre si los servicios limitados como PSN son compatibles con la configuración de direcciones planificada.
Guarde los procedimientos junto con el inventario. El software de documentación técnica puede ayudar a organizar los procedimientos de exportación, conciliación y gestión de excepciones, mientras que IPAM sigue siendo la autoridad para la propiedad de las direcciones.
Una subred sin propietario es un riesgo operativo no resuelto.
Automatice las comprobaciones de superposiciones propuestas, propietarios no asignados y registros incoherentes de DNS o directivas. Marque las desviaciones en vivo para su revisión en lugar de eliminar automáticamente una ruta de producción imprevista.
Cada dirección debe tener un propietario responsable, una ruta prevista y un registro de cambios rastreable. Mantenga las credenciales y el historial de concesiones identificables fuera de repositorios documentales de acceso general.
Cómo asignar y retirar una dirección
Utilice la misma ruta de cambio para un servidor, una ampliación de red de invitados o una subred en la nube. La implementación difiere, pero los requisitos de aprobación, pruebas y retirada no deben desaparecer porque un despliegue esté automatizado.
Siga el ciclo de vida de la asignación
- Registre la solicitud. Indique el propietario, el propósito, el sitio, el protocolo y la vida útil requerida. Identifique cualquier conectividad entrante o dependencia de proveedores.
- Consulte el inventario para verificar solapamientos y capacidad dentro del resumen del sitio. Confirme el método de asignación para la clase de dispositivo.
- Reserve antes de configurar. Registre el prefijo, la fecha de vencimiento o revisión y la referencia del cambio para que las solicitudes paralelas no puedan reclamarlo.
- Cree o amplíe el ámbito de DHCP, la reserva o el registro estático. Para segmentos con pila doble, configure el acuerdo DHCPv6 o SLAAC aprobado.
- Publique el DNS directo e inverso según corresponda. Libere registros AAAA solo después de que el servicio supere las pruebas de IPv6.
- Actualice los objetos de firewall, NAT y rutas a partir de la asignación aprobada. Verifique el origen, el destino y la ruta de retorno previstos.
- Aplique la política de acceso de clientes a través del directorio y el controlador WiFi. Asigne a los empleados y a los invitados a sus VLANs autorizadas en lugar de depender de una frase de paso compartida.
- Capture evidencias. Confirme la concesión (lease) o la entrada de vecino, la respuesta DNS y un evento de asignación que se pueda correlacionar con un usuario, dispositivo o incidencia.
- Al vencer, elimine la asignación y los objetos dependientes, y luego marque el prefijo como en desuso. Verifique que el tráfico residual y las dependencias se hayan detenido antes de devolverlo al conjunto de direcciones (pool).
El diagrama de ciclo de vida resume los controles de cambio sin sustituir a la lista de verificación detallada.
Si la dirección va a enviar correo electrónico, incluya comprobaciones de reputación antes de la activación. La comprobación de listas negras de correo electrónico de MailGenius puede identificar las direcciones de envío listadas, aunque un resultado limpio no garantiza la entrega ni sustituye a una autenticación de correo adecuada.
Haga que el evento de asignación sea rresponsible
Una dirección por sí sola no puede identificar a su titular tras ser reutilizada. Conserve el inicio y el fin de la asignación, el protocolo, el identificador del dispositivo y la referencia de autenticación relevante, utilizando una fuente horaria común para DHCP, RADIUS, controladores y DNS.
El histórico Reglamento de Retención de Datos de 2009 (Directiva CE) del Reino Unido exigía a los proveedores de comunicaciones públicas conservar datos de comunicaciones específicos durante 12 meses, incluida la información de asignación de suscriptores vinculada al tiempo. Desde entonces, ese marco ha sido sustituido y modificado; no es una norma general de retención vigente para redes corporativas.
Establezca la retención según las obligaciones aplicables y las necesidades del negocio. Restrinja el acceso, proteja la integridad y compruebe si un investigador autorizado puede reconstruir una asignación sin exponer los registros de usuarios no relacionados.
Para las conexiones traducidas, conserve los detalles del mapeo necesarios para la atribución, incluidos los puertos donde se comparten direcciones. Un único evento de asignación es el punto de partida, no un sustituto de las pruebas de autenticación y traducción.
Elija entre mantener, alquilar, traducir o renumerar
Comience con los servicios IPv4 que no pueda eliminar: conexiones de socios, listas blancas de proveedores, puntos finales VPN y aplicaciones heredadas. Esas dependencias establecen la huella pública estable mínima que su entorno necesita.
Elija una opción por entorno, no una sola respuesta para toda la organización. Una red de invitados y un servicio orientado a proveedores tienen diferentes requisitos de acceso entrante, atribución y continuidad.
Opciones de retención, concesión, traducción y renumeración de IPv4
| Opción | Cuándo usar | Riesgo principal |
|---|---|---|
| Mantener IPv4 en propiedad | El espacio público existente cubre socios, proveedores y servicios heredados | Los bloques no utilizados quedan ocultos a menos que se escaneen y registren |
| Alquilar espacio IPv4 | El crecimiento es real y el bloque se puede registrar con propietario y ruta | Los rangos alquilados se desvían de los registros de rutas y del registro principal |
| NAT a nivel de operador (CGNAT) | Los clientes solo necesitan acceso saliente y la atribución aún se puede registrar | Las direcciones compartidas complican el registro por usuario y los servicios entrantes |
| Doble pila IPv6 | Los servicios y clientes están preparados para IPv6 con controles equivalentes | Registros de direcciones adicionales y posible omisión si los controles se retrasan |
| Reenumerar | Los resúmenes no se forman o un rango RFC1918 colisiona con una VPC | Riesgo de interrupción del servicio y direcciones codificadas de forma fija en las aplicaciones |
Elija por dependencia, no por conveniencia
Conservar el espacio propio tiene sentido cuando se puede justificar su uso y mantener su autoridad de enrutamiento. No compre ni alquile más espacio simplemente porque los administradores no hayan reconciliado las asignaciones sin uso.
Para los bloques alquilados, documente el arrendador, el uso permitido, los acuerdos de enrutamiento, las condiciones de renovación y el proceso de retirada. Planifique cómo cambiarán las listas de permitidos de los proveedores y los puntos finales publicados externamente si finaliza el alquiler. Un bloque aparentemente disponible no se puede desplegar hasta que la parte adecuada pueda autorizar su anuncio.
Carrier-grade NAT es adecuado para algunas poblaciones de clientes salientes, pero introduce un comportamiento de dirección compartida. Compruebe la compatibilidad de las aplicaciones, la capacidad de los puertos y la habilidad para correlacionar sesiones traducidas antes de considerarlo como una medida de conservación.
El reenumerado suele ser la solución a largo plazo más limpia para las redes privadas superpuestas. Por ejemplo, si el rango de gestión de un hotel adquirido colisiona con una VPC en la nube: la traducción podría restaurar temporalmente una ruta de servicio estrecha, pero no producirá un resumen coherente del sitio ni eliminará las direcciones integradas de las aplicaciones.
Prueba de decisión: Elija la opción que pueda operar, atribuir y retirar de forma segura, no simplemente la que pueda configurar más rápido.
Utilice doble pila (dual-stack) para entornos nuevos que superen las comprobaciones operativas y de compatibilidad. Mantenga las rutas de proveedores con limitaciones en IPv4 hasta que sus requisitos cambien.
Registre la decisión con cada bloque, incluyendo la dependencia que la justifica y la condición que permitiría su retirada. Esto proporciona al siguiente administrador un motivo para mantener la asignación o pruebas de que es momento de eliminarla.
Despliegue la doble pila sin un desvío IPv6
A nivel global, se transfirieron aproximadamente 33 millones de direcciones IPv4 dentro de los sistemas de registros regionales durante 2025, según el informe de direcciones de Geoff Huston. Esa continua actividad de transferencia es un recordatorio útil de que el despliegue de IPv6 no elimina de inmediato la dependencia comercial u operativa de IPv4.
Ejecute IPv6 como un programa controlado. Haga un inventario previo de las aplicaciones y sus dependencias, identificando literales IPv4 incrustados, ACL específicas del protocolo, supuestos de supervisión y proveedores que requieran un extremo IPv4 fijo.
Controle cada expansión
Realice una prueba piloto en un segmento de bajo riesgo con un plan de reversión definido. Evalúe las transacciones de los usuarios, no solo las respuestas de ping correctas, y verifique la conmutación por error, los controles de identidad y la visibilidad de incidentes antes de ampliar la implementación.
- Controlar la publicación. Retenga los registros AAAA hasta que se aprueben las pruebas de aplicaciones, la directiva del firewall y el registro de eventos. Incluya las rutas externas, no solo el acceso interno.
- Proteja los anuncios de router con los controles de conmutación adecuados, como RA Guard donde sea compatible. Traslade la directiva de seguridad IPv4 prevista a reglas IPv6, incluyendo el ICMPv6 necesario en lugar de bloquearlo de forma indiscriminada.
- Normalizar las direcciones en el SIEM. Las formas textuales equivalentes deben correlacionarse de manera coherente. La normalización por sí sola no vinculará las direcciones privadas rotativas, por lo que también debe conservar el contexto del dispositivo y de la identidad.
- Registre la elección de SLAAC o DHCPv6 para cada VLAN. Cuando ambos funcionen de forma intencionada, documente sus funciones y cómo la detección cubre ambos casos.
- Proporcione al servicio de soporte técnico un script que resuelva una dirección asignándola a su dispositivo, período de asignación, prefijo y directiva aplicada. Incluya pruebas independientes para cada protocolo, de modo que la conmutación por error no oculte una ruta con errores.
Mida la preparación y la dependencia por separado
Haga un seguimiento de la preparación técnica frente a los activos y servicios en el alcance del despliegue. Supervise la dependencia de IPv4 como un registro independiente, asignando un propietario y una condición de eliminación para cada servicio restante.
- Cobertura de detección. Cada activo compatible con IPv6 dentro del alcance tiene un registro detectable y un propietario responsable.
- Coherencia de rutas y DNS. Los prefijos anunciados y los registros publicados coinciden con la configuración aprobada, resolviendo cualquier discrepancia.
- Cobertura de directivas. Cada control requerido tiene una implementación de IPv6 y un resultado de prueba registrado.
- Excepciones de exposición. Ningún servicio IPv6 accesible externamente permanece sin explicación o sin aprobación.
- Reducción de dependencias. El registro muestra qué servicios han dejado de requerir IPv4, respaldado por pruebas de transacciones y de conmutación por error.
No declare el éxito solo porque los clientes prefieran IPv6. Declare un segmento listo cuando los administradores puedan operarlo, solucionar problemas y contener un incidente sin recurrir a procedimientos exclusivos de IPv4.
Retire IPv4 solo después de que los propietarios del servicio confirmen que el funcionamiento normal, la recuperación y las conexiones con proveedores ya no dependen de él. Conserve las pruebas de reversión hasta que se haya probado dicha retirada.
Haga que un solo sistema sea el propietario de cada dirección
Elija un sistema de registro de referencia antes de añadir otra hoja de cálculo. Debe contener el prefijo aprobado, el propietario, el método de asignación y las fechas del ciclo de vida, mientras que DHCP, DNS, firewalls y cuentas de la nube proporcionan pruebas de la implementación.
El sistema no es el propietario humano responsable. Nombre a un responsable de red que mantenga la directiva de asignación y delegue las responsabilidades de las subredes en personas capacitadas para aprobar cambios y resolver discrepancias.
Concilie un sitio antes de vincular roles de acceso
Comience con una ubicación acotada en lugar de una migración a escala de toda la infraestructura. Exporte sus ámbitos, reservas, hosts estáticos y rangos en la nube conectados; después, convierta las diferencias en una cola de trabajo controlada.
- Marcar incertidumbres. Identifique superposiciones, asignaciones sin propietario u objetos cuyo propósito nadie pueda explicar.
- Investigar antes de reenumerar. Documente o retire rangos sin propietario solo después de verificar las dependencias y el tráfico.
- Adjuntar los roles de red. Inserte las VLAN del sitio en los prefijos aprobados y distinga el acceso de invitados, personal, gestión e inquilinos.
- Probar cambios de identidad. Confirme que la incorporación, los cambios de rol y las revocaciones generen la directiva de acceso prevista y pruebas de auditoría útiles.
Una cuenta de directorio identifica a una persona; una concesión DHCP identifica una asignación. Vincule esos registros a través de eventos de autenticación y de controlador en lugar de asumir que una dirección pertenece permanentemente a un empleado.
Mantenga diferenciada la capa de identidad inalámbrica
Cuando el acceso inalámbrico necesita esa capa de identidad, ejecutamos Purple como una superposición en la nube sobre los puntos de acceso que el establecimiento ya posee, por lo que no es necesario reemplazarlos. Nuestra plataforma ofrece guest WiFi, seguridad 802.1X para el personal y redes de área privada xPSK, con RADIUS en la nube sustituyendo a FreeRADIUS o Windows NPS para que no haya servidores de autenticación locales que parchear o que puedan fallar.
La compatibilidad depende del soporte del controlador para RADIUS, cambio de autorización (CoA) y jardín vallado (walled garden). Esta es la parcela de identidad inalámbrica, no un sustituto de IPAM, del control de rutas o de los registros del ciclo de vida de direcciones.
Mantenga la autoridad de asignación independiente del servicio de autenticación, con una frontera de integración clara. Un rol de acceso debe seleccionar una red aprobada, no crear una subred no documentada.
Nombre al propietario del plan de direccionamiento y reconcilie la primera ubicación antes de vincularle roles de WiFi. Esto ofrece a los administradores una base sólida para ampliar el acceso sin aumentar la incertidumbre.
Purple proporciona acceso basado en identidad para invitados, personal y redes privadas en los puntos de acceso existentes, ayudándole a conectar las decisiones de acceso inalámbrico con un plan de red documentado. Visite Purple para analizar la compatibilidad de su controlador y cómo la capa de identidad inalámbrica puede adaptarse a su proceso de gestión de direcciones.
