Menos de 30 de los aproximadamente 25 millones de servidores de nombres con sede en Reino Unido tenían direcciones IPv6 cuando se publicó el informe sobre la implementación de IPv6 del gobierno de Reino Unido en 2010. Ese punto de partida histórico ayuda a explicar por qué se construyeron tantos planes de direccionamiento, procedimientos de soporte y registros de activos en torno a IPv4.
Gestionar direcciones IP ahora significa mantener un entorno donde los dispositivos pueden usar cualquiera de los protocolos, a veces sin que los administradores se den cuenta. La disciplina útil 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 en conflicto y la alcanzabilidad no explicada no lo están.
Cuándo usar direcciones estáticas o reservadas por DHCP
En agosto de 2026, el 54.27% de 5,340,321 hosts rastreados eran de pila doble, mientras que el 45.73% permaneció solo como IPv4, de acuerdo con las mediciones del Reino Unido de la Internet Society. Esas son mediciones de hosts rastreados, no un censo de dispositivos empresariales, 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 en la mesa de ayuda, el objeto del firewall y la hoja de trabajo del incidente aún contienen solo IPv4. Trate el dual-stack como un segundo conjunto de registros, incluida la historia de direcciones, en lugar de solo una capacidad de enrutamiento.
Elija un método de asignación por clase de dispositivo antes de trazar subredes. DHCP emite asignaciones de direcciones con límite de tiempo; una reserva le da a un dispositivo en particular una dirección predecible a través de ese mismo servicio. El glosario de DHCP proporciona una referencia útil al explicar esa distinción a colegas fuera del área de redes.
Métodos de asignación de direcciones y cuándo utilizarlos
| Método | Úsalo para | Estabilidad | Riesgo principal |
|---|---|---|---|
| DHCP dinámico | Invitados, contratistas, clientes de estancia corta | Usualmente conservado mediante renovaciones; elegible para reusar tras vencer | La reutilización oculta quién tenía la dirección sin registros |
| Reserva DHCP | Impresoras, puntos de acceso, cámaras, IoT | Dirección fija emitida aún por DHCP | Reserva obsoleta después de que el dispositivo se retira |
| Configuración estática | Routers, firewalls, DNS, gestión fuera de banda | Permanente hasta que se modifique manualmente | Dirección huérfana sin registro de propietario |
| SLAAC | Clientes IPv6 ordinarios en un /64 | Las direcciones estables pueden coexistir con direcciones de privacidad rotativas | Host invisible si IPAM nunca lo detecta |
| DHCPv6 | Clientes IPv6 compatibles que requieren registros de asignación del lado del servidor | Concesión con registro del lado del servidor | Desviación de alcance 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, así que no use la rotación de DHCP como un control de seguridad.
Para una sede hipotética, una concesión para invitados de ocho horas podría ser adecuada para los visitantes diurnos, mientras que una LAN para el personal podría comenzar con concesiones de uno a siete días. Estos son puntos de partida de 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 equipos que necesiten un direccionamiento estable pero que deban seguir siendo revocables 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 más justificable para la infraestructura que debe iniciar 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, luego 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 de que cada dispositivo deba comportarse de manera idéntica.
Cómo dimensionar subredes y dejar espacio para crecer
Ajuste el tamaño para los dispositivos que pueden conectarse simultáneamente, incluidos los reemplazos, clientes temporales e infraestructura. No elija un prefijo solo porque otro sitio lo utilizó.
Tamaños de prefijo predeterminados por zona de red
Estos son puntos de partida de ingeniería. Valide la demanda de hosts, las reservas en la nube y el soporte de la plataforma antes de adoptar una fila.
| Zona | Plan IPv4 | Plan IPv6 | Nota de planificación |
|---|---|---|---|
| LAN de personal o usuarios | /23 o /24 | /64 | Deja libre el siguiente bloque antes de que se llene la VLAN |
| WiFi para invitados | /22 para un recinto concurrido | /64 | Concesiones cortas y sin ruta hacia el personal o los servidores |
| Servidores e infraestructura | /24 o más pequeño, en su mayoría estático | /64 | Cada host administrado debe nombrarse en el DNS directo e inverso |
| Administración y fuera de banda | /26 o /27 | /64 | No enrutado hacia invitados ni expuesto directamente a internet |
| Enlace punto a punto | /31 | /127 | Usa solo donde ambos extremos lo admitan |
| Agregado por sitio | Un bloque resumible por sitio | Frecuentemente un /48 por sitio | Anuncia el resumen, no cada VLAN |
| VPC o VNet en la nube | Espacio RFC1918 sin superposición | Asignación IPv6 del proveedor | Verifica la superposición antes de cada fusión o emparejamiento |
Utilice una calculadora de subredes para verificar los límites y la capacidad en lugar de hacer aritmética de prefijos de memoria. Para las LAN IPv4 ordinarias, distinga el total de direcciones 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 redes LAN normales y segmentos de seguridad, no subredes de clientes más pequeñas con la intención de conservar espacio de direcciones.
Construya la jerarquía antes de completarla
Asigne a cada sitio un bloque resumido IPv4 alineado. Cuando la asignación lo permita, otórguele también un agregado IPv6, y luego divida los prefiijos de VLAN dentro de esos límites.
Reserve un bloque de crecimiento adyacente y alineado correctamente 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 verifique el límite binario antes de prometer una expansión sin complicaciones.
El espacio de direcciones privadas no es globalmente único. Las oficinas, empresas adquiridas y proyectos en la nube pueden elegir de forma independiente rangos superpuestos y descubrir el conflicto cuando alguien solicite un emparejamiento o peering.
Un esquema de un solo sitio puede mantenerse legible sin listar direcciones individuales:
| Rol de 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 |
| Administració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 de rutas es una comodidad de enrutamiento, no un permiso para que todas las zonas se comuniquen. Mantenga explícitos los límites de las políticas de invitados, administración y servidores.
Cómo crear un inventario de direcciones controlado por versiones
Un inventario de direcciones solo es útil si refleja tanto las asignaciones planificadas como la configuración en vivo. La gestión de direcciones IP (IPAM) registra quién es el propietario de cada prefijo, qué admite y dónde aparece la información de su dirección. Mantenga un propietario, una ruta prevista y un registro rastreable para cada dirección.
Registre el prefijo, propietario, propósito de negocio, sitio, zona de seguridad, método de asignación y fecha de revisión. Incluya fechas de vencimiento para asignaciones temporales, además de referencias de registro y enrutamiento para bloques públicos. Controle las versiones del inventario para que cada cambio cuente con una aprobación y una diferencia de versiones clara.
Concilie la configuración en un orden repetible
- Registros de registro. Confirma las asignaciones públicas que la organización tiene derecho a usar.
- Zonas DNS. Exporta registros directos e inversos, incluyendo entradas A y AAAA obsoletas.
- Registros DHCP. Recopila concesiones, reservas, exclusiones y asignaciones DHCPv6.
- Objetos de firewall y NAT. Registra direcciones traducidas, servicios publicados y reglas de gestión.
- Redes en la nube. Exporta asignaciones de VPC, VNet y subredes en todas las cuentas o suscripciones relevantes.
- Estado de enrutamiento. Compara los anuncios configurados con las rutas aprendidas e instaladas.
La exportación más reciente no es automáticamente autoritativa. Una subred en la nube no documentada puede ser legítima; un objeto de firewall antiguo puede exponer un servicio que actualmente no tiene propietario. 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 una marca independiente: una subred activa también puede estar expuesta externamente.
Verifique lo que parece vacío
Verifique cada rango de direcciones que la organización posee o está autorizada a evaluar, incluidos los rangos que no se consideran en uso. Esto ayuda a descubrir asignaciones y servicios olvidados sin extender las verificaciones 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, 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 restringidos como PSN son compatibles con la configuración de direcciones planeada.
Mantenga los procedimientos junto al 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 para detectar superposiciones propuestas, propietarios faltantes y registros inconsistentes de DNS o políticas. Marque las desviaciones en tiempo real para revisión en lugar de eliminar automáticamente una ruta de producción no esperada.
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 los repositorios de documentación de acceso general.
Cómo asignar y retirar una dirección
Utilice la misma ruta de cambio para un servidor, la expansión de una red de invitados o una subred en la nube. La implementación difiere, pero los requisitos de aprobación, evidencia y retiro no deben desaparecer porque un despliegue esté automatizado.
Siga el ciclo de vida de asignación
- Abre la solicitud. Indica el propietario, el propósito, el sitio, el protocolo y la vigencia requerida. Identifica cualquier conectividad entrante o dependencia de proveedores.
- Consulta el inventario para verificar la superposición y la capacidad dentro del resumen del sitio. Confirma el método de asignación para la clase de dispositivo.
- Reserva antes de configurar. Registra el prefijo, la fecha de vencimiento o revisión y la referencia del cambio para que las solicitudes paralelas no puedan reclamarlo.
- Crea o amplía el alcance de DHCP, la reserva o el registro estático. Para segmentos de pila doble, configura el esquema DHCPv6 o SLAAC aprobado.
- Publica el DNS directo e inverso según corresponda. Libera los registros AAAA solo después de que el servicio apruebe las pruebas de IPv6.
- Actualiza el firewall, NAT y los objetos de ruta a partir de la asignación aprobada. Verifica la fuente, el destino y la ruta de retorno previstos.
- Aplica la política de acceso de clientes a través del directorio y el controlador WiFi. Asigna a los empleados y visitantes a sus VLAN autorizadas en lugar de depender de una frase de contraseña compartida.
- Captura evidencia. Confirma la concesión o la entrada de vecino, la respuesta de DNS y un evento de asignación que se pueda correlacionar con un usuario, dispositivo o ticket.
- Al vencer, elimina la asignación y los objetos dependientes, luego marca el prefijo como en desuso. Verifica que el tráfico residual y las dependencias se hayan detenido antes de devolverlo al grupo.
El diagrama de ciclo de vida resume los controles de cambio sin sustituir la lista de verificación detallada.
Si la dirección enviará correo electrónico, incluya verificaciones de reputación antes de la activación. La búsqueda en lista negra de correo electrónico de MailGenius puede identificar las direcciones de envío en la lista, aunque un resultado limpio no garantiza la entrega ni reemplaza la autenticación de correo adecuada.
Haga que el evento de asignación sea auditable
Una dirección por sí sola no puede identificar a su titular después de ser reutilizada. Conserve el inicio y fin de la asignación, el protocolo, el identificador del dispositivo y la referencia de autenticación relevante, utilizando una fuente de tiempo común para DHCP, RADIUS, controladores y DNS.
El histórico Reglamento sobre la Retención de Datos de Reino Unido (Directiva CE) de 2009 exigía a los proveedores públicos de comunicaciones conservar datos de comunicaciones específicos durante 12 meses, incluida la información de asignación de suscriptores vinculada al tiempo. Ese marco ha sido reemplazado y modificado desde entonces; no es una regla de retención actual general para redes empresariales.
Establezca la retención según las obligaciones aplicables y las necesidades del negocio. Restrinja el acceso, proteja la integridad y pruebe si un investigador autorizado puede reconstruir una asignación sin exponer registros de usuarios no relacionados.
Para conexiones traducidas, conserve los detalles de mapeo necesarios para la atribución, incluidos los puertos donde se comparten direcciones. Un evento de asignación único es el punto de partida, no un sustituto de la evidencia de autenticación y traducción.
Elija entre conservar, arrendar, traducir o renumerar
Comience con los servicios IPv4 que no pueda eliminar: conexiones con socios, listas de permitidos de proveedores, puntos de enlace 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 | Usar cuando | Riesgo principal |
|---|---|---|
| Mantener IPv4 propio | El espacio público existente cubre a socios, proveedores y servicios heredados | Los bloques no utilizados se ocultan a menos que se escaneen y registren |
| Arrendar espacio IPv4 | El crecimiento es real y el bloque se puede registrar con propietario y ruta | Los rangos arrendados se desvían del registro y de los registros de ruta |
| 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 (Dual-stack) IPv6 | Los servicios y clientes están listos para IPv6 con controles coincidentes | Registros de direcciones adicionales y una omisión si los controles se retrasan |
| Renumera | Los resúmenes no se forman o un rango RFC1918 colisiona con una VPC | Riesgo de interrupción y direcciones codificadas de forma rígida en las aplicaciones |
Elija por dependencia, no por conveniencia
Mantener el espacio de direcciones propio tiene sentido cuando se puede justificar su uso y mantener su autoridad de enrutamiento. No compre ni arriende más solo porque los administradores no han conciliado las asignaciones no utilizadas.
Para bloques arrendados, documente el arrendador, el uso permitido, los acuerdos de enrutamiento, las condiciones de renovación y el proceso de retiro. Planifique cómo cambiarán las listas de permitidos de los proveedores y los puntos de enlace publicados externamente si finaliza el arrendamiento. Un bloque aparentemente disponible no se puede implementar hasta que la parte adecuada pueda autorizar su anuncio.
El NAT a nivel de operador (CGNAT) es adecuado para algunas poblaciones de clientes salientes, pero introduce un comportamiento de dirección compartida. Verifique la compatibilidad de las aplicaciones, la capacidad de los puertos y la habilidad de 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 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 manera segura, no solo la que pueda configurar más rápido.
Utilice dual-stack para nuevos entornos que superen las comprobaciones de compatibilidad y operativas. Mantenga las rutas restringidas de proveedores 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 retiro. Esto le da al siguiente administrador una razón para conservar la asignación, o evidencia de que es momento de eliminarla.
Implemente dual-stack sin omitir la seguridad en 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 actividad de transferencia continua es un recordatorio útil de que la implementación de IPv6 no elimina de inmediato la dependencia comercial y operativa de IPv4.
Ejecute IPv6 como un programa controlado. Inventaríe primero las aplicaciones y dependencias, buscando literales IPv4 embebidas, ACL específicas de protocolo, suposiciones de monitoreo y proveedores que requieran un punto de enlace IPv4 fijo.
Controle cada expansión
Realiza una prueba piloto en un segmento de bajo riesgo con un plan de reversión definido. Evalúa las transacciones del usuario, no solo los pings exitosos, y verifica la conmutación por error, los controles de identidad y la visibilidad de incidentes antes de ampliar el despliegue.
- Control de publicación. Retén los registros AAAA hasta que se aprueben las pruebas de aplicaciones, la política de firewall y el registro de eventos. Incluye rutas externas, no solo acceso interno.
- Protege los anuncios de router con controles de switch adecuados, como RA Guard donde sea compatible. Traduce la política de seguridad IPv4 prevista a reglas IPv6, incluyendo el ICMPv6 necesario en lugar de bloquearlo de forma indiscriminada.
- Normaliza las direcciones en el SIEM. Las formas textuales equivalentes deben correlacionarse de manera consistente. La normalización por sí sola no vinculará las direcciones de privacidad rotativas, por lo que también debes conservar el contexto del dispositivo y de la identidad.
- Registra la elección de SLAAC o DHCPv6 para cada VLAN. Cuando ambos funcionen intencionalmente, documenta sus roles y cómo el descubrimiento cubre ambos.
- Proporciona al equipo de soporte un script que resuelva una dirección con su dispositivo, periodo de asignación, prefijo y política aplicada. Incluye pruebas separadas para cada protocolo para que la conmutación por error no oculte una ruta dañada.
Mida la preparación y la dependencia por separado
Haga un seguimiento de la preparación técnica en comparación con los activos y servicios dentro del alcance del despliegue. Gestione la dependencia de IPv4 como un registro independiente, con un propietario y una condición de eliminación para cada servicio restante.
- Cobertura de descubrimiento. Cada activo con capacidad IPv6 dentro del alcance tiene un registro localizable y un propietario responsable.
- Consistencia de ruta y DNS. Los prefijos anunciados y los registros publicados coinciden con la configuración aprobada, resolviendo cualquier discrepancia.
- Cobertura de políticas. Cada control requerido tiene una implementación 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 victoria 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.
Descarte IPv4 solo después de que los propietarios del servicio confirmen que la operación normal, la recuperación y las conexiones con proveedores ya no dependen de este. Conserve las pruebas de reversión hasta que se haya probado dicho descarte.
Haga que un solo sistema sea el propietario de cada dirección
Elija un sistema de registro antes de agregar 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 en la nube proporcionan evidencia de la implementación.
El sistema no es el propietario humano responsable. Nombre a un responsable de red que mantenga la política de asignación y delegue las responsabilidades de las subredes en personas que puedan aprobar cambios y resolver discrepancias.
Concilie un sitio antes de vincular roles de acceso
Comience con un sitio delimitado en lugar de una migración en toda la empresa. Exporte sus ámbitos, reservas, hosts estáticos y rangos de nube conectados, y luego convierta las diferencias en una cola de trabajo controlada.
- Marcar incertidumbre. Identifique superposiciones, asignaciones sin propietario u objetos cuyo propósito nadie pueda explicar.
- Investigar antes de renumerar. Documente o retire los rangos sin propietario solo después de verificar las dependencias y el tráfico.
- Asignar los roles de red. Mapee las VLAN del sitio a prefijos aprobados y distinga el acceso de invitados, personal, administración e inquilinos.
- Probar cambios de identidad. Confirme que la incorporación, los cambios de rol y la revocación generen la política de acceso prevista y evidencia de auditoría útil.
Una cuenta de directorio identifica a una persona; una concesión de DHCP identifica una asignación. Vincule esos registros a través de eventos de autenticación y del controlador, en lugar de asumir que una dirección pertenece permanentemente a un empleado.
Mantenga independiente la capa de identidad inalámbrica
Cuando el acceso inalámbrico requiere esa capa de identidad, ejecutamos Purple como una superposición en la nube sobre los puntos de acceso que la sede ya posee, por lo que no es necesario reemplazar nada. Nuestra plataforma ofrece WiFi para invitados, seguridad 802.1X para el personal y redes privadas de área xPSK, con RADIUS en la nube reemplazando a FreeRADIUS o Windows NPS para que no haya servidores de autenticación locales que parchear o con fallas de conmutación.
La compatibilidad depende del soporte de RADIUS, cambio de autorización (CoA) y portal cautivo del controlador. Esta es la sección de identidad inalámbrica, no un reemplazo para IPAM, control de rutas o registros de ciclo de vida de direcciones.
Mantenga la autoridad de asignación separada del servicio de autenticación, con un límite de integración claro. Un rol de acceso debe seleccionar una red aprobada, no crear una subred no documentada.
Nombre al propietario del plan de direcciones y concilie el primer sitio antes de vincular roles de WiFi a este. Esto otorga 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.
