BIBLIOTECA ASTRACode Cyber

CAPÍTULO 27 · PARTE III

IPv4, IPv6, direccionamiento y subnetting

Cómo los prefijos, las rutas y los ámbitos convierten bits en decisiones de entrega, cómo difieren IPv4 e IPv6 en operación y cómo subnetting, agregación, ND, SLAAC y MTU condicionan los controles de seguridad.

Nivel N2–N3 · Estado published

El prefijo decide más que la apariencia de una dirección

Un equipo puede tener una interfaz activa, responder a un vecino y aun así no tener una ruta válida hacia el destino que la persona usuaria escribió. La dirección visible no contiene por sí sola la decisión de entrega: hay que interpretarla junto con su prefijo, la tabla de rutas, el ámbito de la dirección, el siguiente salto y el tamaño máximo que admite el camino. La misma cadena de bits puede ser una dirección de interfaz, un identificador de grupo, una dirección no asignable o una ruta agregada, según el protocolo y el contexto.

Este capítulo construye un modelo operativo para IPv4 e IPv6. El caso conductor sigue a un servicio ficticio de inventario de Northstar que debe comunicarse entre dos segmentos, primero con IPv4 y después con IPv6. No se trata de un tutorial de comandos: cada cálculo y cada decisión se usan para responder una pregunta de seguridad o de diagnóstico. El objetivo es poder derivar una red y un rango, explicar qué significa on-link, comparar ARP con Neighbor Discovery (ND), distinguir una dirección de una identidad y formular un claim que no exceda la evidencia.

Alcance, prerrequisitos y resultados observables

Se presupone el modelo de capas, encapsulación, puntos de observación y Ethernet/ARP de los capítulos 25 y 26. Routing, forwarding, NAT y caminos asimétricos se desarrollan en el capítulo 28; TCP, UDP, DHCP y DNS tienen capítulos propios. Aquí se explica sólo lo necesario para que el direccionamiento sea inteligible: prefijos, selección de ruta, semántica de direcciones, ND, SLAAC, MTU y sus límites de seguridad.

Al terminar, el lector debería poder:

Bits, prefijos y la frontera que sí se puede calcular

Comparación de IPv4 /26, IPv6 /56 subdividido en /64 y cuatro /24 agregados en /22, con límites binarios, capacidad de formato y alineación contigua.
El prefijo fija fronteras; la capacidad no cuenta hosts activos.

La agregación exige bloques contiguos y alineados.

Una dirección IPv4 tiene 32 bits y una IPv6 tiene 128. La notación CIDR (Classless Inter-Domain Routing) escribe la dirección seguida de una barra y el número de bits de prefijo: 192.0.2.141/26 o 2001:db8:1234:5600::34/64. El prefijo es la parte que, en el contexto de una tabla de rutas o de una interfaz, identifica un conjunto de direcciones; los bits restantes forman el espacio que puede subdividirse o asignarse. RFC 4632 describe CIDR como una estrategia de asignación y agregación sin las antiguas clases A, B y C; el límite no se deduce de un octeto «natural». RFC 4632, §§2–5

En IPv4, una máscara convierte la operación en bits: los 1 son prefijo y los 0 son host. Para 192.0.2.141/26, la máscara es 255.255.255.192, porque los primeros 26 bits quedan fijos. El último octeto se agrupa en bloques de 64:

dirección       192.0.2.141
máscara /26     255.255.255.192
red             192.0.2.128
broadcast       192.0.2.191
hosts del rango 192.0.2.129–192.0.2.190

El cálculo se puede comprobar con una operación AND entre dirección y máscara: 141 AND 192 = 128. El tamaño del bloque es 2^(32−26) = 64; en el modelo clásico de una subred IPv4, dos valores quedan reservados para identificar la red y el broadcast, de modo que hay 62 direcciones de host utilizables. Ese último conteo es una convención de asignación, no una garantía universal: enlaces punto a punto, interfaces virtuales y políticas del sistema pueden tratar las direcciones de manera distinta. La dirección de red y el broadcast no deben confundirse con «servidor especial» ni con una propiedad de autenticación.

El mismo método permite subnetting. Si una organización recibe 198.51.100.0/24 y necesita cuatro subredes iguales, toma dos bits del espacio de host y obtiene /26: 198.51.100.0/26, .64/26, .128/26 y .192/26. Cada bloque tiene 64 direcciones; en el modelo clásico, 62 utilizables. Si necesita ocho bloques, toma tres bits y obtiene /27, con 32 direcciones por bloque. La elección correcta depende de hosts, gateways, reservas, crecimiento y política; no se justifica rellenando capacidad porque «/24 es lo habitual».

IPv6 usa la misma idea matemática con 128 bits y representación hexadecimal comprimida. En 2001:db8:1234:5600::/56, los primeros 56 bits identifican el prefijo delegado. Si la política de la organización usa subredes /64, quedan 8 bits para el identificador de subred: 2001:db8:1234:5600::/64 hasta 2001:db8:1234:56ff::/64, es decir, 256 prefijos /64. En el modelo unicast común que emplea identificadores de interfaz de 64 bits, cada /64 deja esos 64 bits restantes; no es una regla que deba extrapolarse sin revisar el tipo de dirección y el enlace. Ese espacio tampoco significa que deban crearse 2^64 dispositivos ni que todos sean alcanzables: expresa capacidad del formato y de la asignación. RFC 4291 define la arquitectura y la división entre prefijo de subred e identificador de interfaz; RFC 4862 exige que, para formar una dirección mediante SLAAC, la longitud del prefijo anunciado y la del identificador de interfaz aplicable sumen 128. RFC 4291, §§2–2.5.4; RFC 4862, §5.5.3

La notación no es una propiedad estética. 2001:db8:1234:5600::34/64 y 2001:db8:1234:5600::34/56 describen el mismo valor de 128 bits acompañado de dos fronteras diferentes. Una herramienta o una configuración que cambia el prefijo puede cambiar la decisión on-link, el conjunto de vecinos y la ruta seleccionada sin cambiar la dirección textual.

CIDR, agregación y el coste de una frontera demasiado amplia

Un prefijo puede anunciarse como una unidad más grande que varios prefijos concretos. 198.51.100.0/22 cubre los cuatro /24 alineados 198.51.100.0/24 a 198.51.103.0/24: el tercer octeto va de 100 a 103 porque /22 deja 10 bits de host y el límite de bloque es múltiplo de cuatro. Esto reduce entradas y puede estabilizar el control de rutas, pero sólo es correcto si el mismo siguiente salto puede alcanzar todo el conjunto y si la política acepta anunciarlo. Agregar 198.51.100.0/24 con 198.51.104.0/24 no produce /22: hay un hueco (.103), y un anuncio que lo cubriera también capturaría direcciones no asignadas al servicio.

La agregación no es automáticamente una mejora de seguridad. Un prefijo agregado puede atraer tráfico de un rango que no debía ser alcanzable, ocultar una ruta más específica retirada o ampliar el radio de un error de configuración. En una evaluación hay que comparar el prefijo anunciado, la tabla efectiva, el siguiente salto y el estado de los enlaces; el tamaño reducido de una tabla no prueba aislamiento ni disponibilidad. RFC 4632 trata la agregación como una cuestión de asignación, anuncios y topología, no como autorización de aplicaciones. RFC 4632, §§4–11

Comparación IPv4/IPv6 desde prefijo y ruta hasta ARP o ND y envío al siguiente salto, conservando el destino IP y separando ruta de autorización.
La ruta decide el siguiente salto; el vecino no es el destino IP.

ARP y ND cumplen funciones relacionadas, pero no son el mismo protocolo.

La decisión local responde primero si el destino pertenece a una red directamente conectada. «On-link» significa que el host puede intentar entregar al vecino mediante el mecanismo del enlace —ARP en IPv4 o ND en IPv6—; no significa que dos direcciones parecidas sean una identidad común, que estén en el mismo switch físico ni que la aplicación vaya a aceptar el tráfico. Si el destino no es on-link, el host busca una ruta que indique un siguiente salto o una interfaz de salida. Una ruta por defecto (0.0.0.0/0 o ::/0) es el último recurso, no una prueba de que el gateway conozca el destino.

Cuando varias rutas coinciden, el forwarding IPv4 busca la ruta más específica (el prefijo más largo) antes de resolver otros criterios de la implementación o del protocolo de routing; RFC 1812 lo formula en su algoritmo de determinación del siguiente salto. RFC 1812, §§5.2.4.1–5.2.4.4 Supongamos esta tabla IPv4:

10.24.0.0/16       vía 10.24.8.1
10.24.8.0/24       vía 10.24.8.254
0.0.0.0/0          vía 10.24.8.1

Para 10.24.8.77, coinciden las tres entradas; gana /24 y el siguiente salto es 10.24.8.254. Para 10.24.9.77, coincide /16 y se usa 10.24.8.1. Para 203.0.113.10, sólo coincide la ruta por defecto. Si el host tiene máscara 10.24.8.0/25, 10.24.8.77 sigue siendo on-link, pero 10.24.8.200 ya requiere una ruta; cambiar la máscara altera la topología lógica que el host cree tener. En un diagnóstico, por tanto, hay que conservar la dirección, el prefijo, la tabla de rutas y la interfaz: mirar sólo la dirección es insuficiente.

El gateway no es necesariamente el destino final. En la trama inicial, el destino de enlace será la MAC del siguiente salto; el datagrama IP conserva el destino final. En IPv6 ese vecino puede identificarse por una dirección link-local, por ejemplo fe80::1, mientras la aplicación usa una dirección global. La etiqueta «gateway» describe una función de reenvío en un contexto, no una autoridad universal ni un control de acceso.

Semántica y ámbitos de las direcciones

Una dirección es un identificador usado por un protocolo en un ámbito, no una credencial. El alcance puede ser local a la interfaz, al enlace, a un sitio administrativo, a una organización o global; su interpretación depende de la familia, el prefijo reservado, la tabla y la configuración. La dirección de origen puede ser falsificada en algunos trayectos, y una dirección legítima puede cambiar de interfaz, nodo virtual o ruta. Para atribuir una acción hacen falta autenticación, telemetría y contexto adicional.

En IPv4 son importantes estas distinciones:

IPv6 define direcciones de 128 bits, unicast, anycast y multicast; no define broadcast, cuya función se cubre con multicast. RFC 4291 identifica, entre otros, ::/128 como no especificada, ::1/128 como loopback, fe80::/10 como link-local y ff00::/8 como multicast. Las direcciones anycast se toman del espacio unicast y no se distinguen por la sintaxis: el routing determina qué miembro del conjunto recibe el paquete. RFC 4291, §§2–2.5.3 y §2.7

Las direcciones Unique Local (fc00::/7) están definidas para uso local por RFC 4193, con un diseño que evita depender de una asignación global; no equivalen automáticamente a «red segura». 2001:db8::/32 está reservado para documentación por RFC 3849 y no debe usarse como dirección productiva. La tabla de IANA mantiene los registros de espacios especiales y sus usos; consultar el registro vigente es preferible a copiar listas históricas. RFC 4193, §§3–4; RFC 3849, §4; IANA IPv4 Special-Purpose Address Registry; IANA IPv6 Special-Purpose Address Registry

El ámbito tampoco se deduce sólo de la visibilidad. Una dirección link-local puede ser válida y necesaria para ND en un enlace, pero no identifica por sí misma a una persona o un equipo estable. Una dirección temporal puede mejorar privacidad y complicar correlación; una dirección estable puede facilitar inventario y aumentar exposición de metadatos. La decisión profesional explicita qué propiedad necesita: alcanzabilidad, unicidad local, estabilidad, confidencialidad de la identidad o autorización.

IPv4 e IPv6: qué cambia operativamente

IPv4 y IPv6 comparten el concepto de prefijo, tabla de rutas y siguiente salto, pero no deben tratarse como dos grafías del mismo protocolo. IPv4 tiene 32 bits, usa ARP como protocolo separado para resolución de vecinos en Ethernet y admite fragmentación por routers bajo condiciones de la cabecera IPv4. IPv6 tiene 128 bits, integra opciones mediante cabeceras de extensión, usa ICMPv6 Neighbor Discovery en lugar de ARP y exige que los routers no fragmenten en tránsito. Estos contrastes afectan la configuración, la telemetría, los filtros y los controles de seguridad.

ND combina descubrimiento de routers, resolución de vecinos, detección de alcanzabilidad y DAD mediante mensajes ICMPv6; RFC 4861 describe el protocolo y su uso de multicast de nodo solicitado en vez de broadcast general. RFC 4861, §§1–3 y 7 Un host IPv6 puede recibir un RA con prefijos y flags, formar una dirección mediante SLAAC y ejecutar DAD para detectar duplicados visibles bajo las condiciones del protocolo. DAD no garantiza unicidad absoluta frente a pérdida, partición, filtrado o un vecino que no responda. RFC 4862 describe la secuencia de configuración, los estados de dirección y las condiciones de validez; SLAAC no significa que toda política de red, DNS o autorización quede resuelta. RFC 4862, §§4–5

Ejemplo: en un enlace, el router anuncia 2001:db8:55:10::/64 y el host forma 2001:db8:55:10:7a2b::34/64 junto con una link-local fe80::.... Para alcanzar 2001:db8:55:20::80, la tabla selecciona una ruta distinta de la del prefijo conectado y el host usa el router aprendido por RA; para alcanzar un vecino en 2001:db8:55:10::/64, usa ND directamente. Si un nodo con acceso al enlace puede emitir RA que el host acepta y no existe una mitigación efectiva, esos anuncios pueden influir en routers por defecto, prefijos y parámetros. La precondición importa: un RA filtrado por una política comprobada o rechazado por el host no produce esa transición. RFC 4861 define el procesamiento del host; RFC 7113 documenta límites y mejoras de RA-Guard en bridges. RFC 4861, §6.3; RFC 7113 La consecuencia no es «IPv6 es inseguro», sino que un control que sólo inspecciona ARP o sólo aplica una política IPv4 no cubre necesariamente ND, RA, direcciones globales y link-local.

IPv6 permite múltiples direcciones por interfaz. RFC 6724 define un algoritmo predeterminado para seleccionar direcciones de origen y destino mediante reglas que consideran, entre otros factores, alcance, coincidencia y una tabla de políticas; administradores e implementaciones pueden configurar políticas adicionales. RFC 6724, §§2 y 5 Por ello un log debe conservar familia, dirección elegida, interfaz, prefijo observado, puerto, política relevante y correlación temporal. Un control de acceso que lista únicamente IPv4 puede producir una falsa sensación de cobertura si el servicio escucha también en IPv6. La operación dual stack debe evaluarse como dos caminos relacionados, no como una sola pila con una etiqueta de versión.

Caso conductor: Northstar y dos decisiones distintas

Northstar asigna el segmento de inventario 10.24.8.0/27 a sensores IPv4 y 2001:db8:55:10::/64 a los mismos sensores IPv6. Un sensor tiene 10.24.8.10/27 y 2001:db8:55:10::10/64; el servicio de inventario está en 10.24.8.20/27 y 2001:db8:55:10::20/64. Un gateway en 10.24.8.1 y fe80::1 ofrece la salida hacia el centro de datos.

Para 10.24.8.20, la máscara /27 (255.255.255.224) produce el bloque .0–.31; .10 y .20 son on-link. El sensor resuelve la asociación IPv4–MAC de .20 mediante ARP y envía una trama al vecino. Para 10.24.8.40, el bloque ya no coincide: .40 pertenece a .32–.63, así que el sensor debe usar una ruta y resolver la MAC del gateway .1, no la del servicio .40. Si alguien «arregla» el fallo ampliando la máscara a /24, puede restaurar una prueba local y a la vez borrar una frontera de segmentación que sustentaba una política.

Para 2001:db8:55:10::20, el prefijo /64 coincide y ND resuelve al vecino. Para 2001:db8:55:20::20, no coincide; la ruta por defecto o una ruta más específica conduce al router fe80::1. No se envía un ARP por la dirección global, no se usa broadcast y la dirección link-local del gateway no es el destino final de la aplicación. Una captura en el enlace puede mostrar ICMPv6 y la trama, pero para saber si el servicio procesó la solicitud hace falta evidencia del socket o del proceso de inventario.

Controles positivos y negativos del caso

Un control positivo para la hipótesis «el destino es on-link» es calcular explícitamente el prefijo y observar una resolución de vecino seguida de tráfico hacia la dirección final. Un control negativo cambia sólo el destino a 10.24.8.40 o 2001:db8:55:20::20: debería observarse una decisión de siguiente salto y no una resolución directa del servicio. Si ambos ensayos producen idéntico tráfico, la hipótesis sobre la máscara, la tabla o el punto de captura queda cuestionada.

Un segundo control positivo comprueba que una política de firewall se aplica a ambas familias con el mismo alcance. El negativo presenta una conexión IPv6 mientras la regla sólo enumera IPv4. Si la conexión pasa, no se concluye automáticamente una vulnerabilidad explotable: hay que establecer que el servicio está alcanzable, que la política pretendía cubrirlo, qué activos y rutas existen y qué impacto tiene el camino no filtrado.

MTU, fragmentación y qué puede observarse

Árbol de diagnóstico que separa familia y prefijo, tabla y vecino, tamaño y PMTU, controles positivo/negativo y conclusión con incertidumbre.
Diagnosticar MTU y dual stack exige separar hipótesis.

No ver Packet Too Big no adjudica una causa única.

La Maximum Transmission Unit (MTU) es el tamaño máximo de la unidad IP que un enlace admite en su contexto; encapsulaciones y túneles pueden reducir el tamaño efectivo del camino. No es sinónimo de tamaño de trama, ni una propiedad constante de una aplicación. En IPv4 un router puede fragmentar un datagrama si la cabecera y la configuración lo permiten; en IPv6 los routers no fragmentan en tránsito. El origen puede usar una cabecera Fragment para IPv6 y el destino reensambla, mientras un router que encuentra un paquete demasiado grande debe informar mediante ICMPv6 Packet Too Big; RFC 8200 fija además 1280 octetos como MTU mínimo de enlace IPv6. RFC 8200, §§4.5 y 5; RFC 8201, §§4–5

Como cálculo ilustrativo, en un camino con MTU IP 1500, cabeceras base y TCP sin opciones, un segmento TCP IPv4 deja 1460 octetos de datos (1500−20−20) y uno IPv6 deja 1440 (1500−40−20). RFC 9293 define MSS como el mayor bloque de datos TCP que el receptor está dispuesto a aceptar, no como una promesa de tamaño de cada segmento. RFC 9293, §3.7.1 Opciones, encapsulación, seguridad, otro PMTU, MSS clamping y decisiones de implementación pueden reducir el valor efectivo. La cifra no garantiza que toda aplicación envíe o reciba mensajes de ese tamaño.

La fragmentación crea una frontera de observación. Ver el primer fragmento no prueba que los demás llegaran ni que el destino reensambló y entregó el datagrama al transporte. Los filtros que inspeccionan sólo el primer fragmento pueden omitir puertos presentes en otra parte; una política de inspección debe declarar cómo reensambla, qué timeout usa y qué hace con solapamientos. En IPv6 RFC 8200 prohíbe crear fragmentos solapados y RFC 5722 exige descartar el conjunto cuando se recibe un solapamiento; un dispositivo concreto puede tener otros límites operativos. RFC 5722, §4

Un fallo «sólo IPv6» después de añadir un túnel puede ser una señal de Packet Too Big filtrado, una ruta asimétrica o una política que trata ICMPv6 como ruido. Un control positivo captura el mensaje y correlaciona el tamaño con la ruta; uno negativo usa un payload menor y comprueba si el servicio responde. Si el primer control funciona y el segundo no, la evidencia orienta hacia MTU, pero aún no adjudica cuál equipo bloqueó o generó el problema.

Errores de seguridad y decisiones de control

El direccionamiento participa en controles, pero no es una identidad confiable por sí mismo. Los fallos más costosos son de alcance:

En cada caso hay que distinguir observación, inferencia e impacto. Ver un RA inesperado es una observación; la hipótesis puede ser un router no autorizado o una configuración legítima; el impacto potencial es cambiar rutas o prefijos; el impacto demostrado requiere confirmar que una política efectiva cambió y que un activo fue alcanzable o desviado.

Transferencia profesional: construir un claim verificable

Un informe no debería escribir «la red está segmentada porque las IP son diferentes» ni «IPv6 está protegido por SLAAC». Un claim más útil fija sujeto, familia, prefijo, ventana, punto de decisión y límite:

Durante la ventana T, el sensor 10.24.8.10/27 trató 10.24.8.20 como destino on-link y resolvió su vecino mediante ARP; para 10.24.8.40 seleccionó el gateway 10.24.8.1. La evidencia procede de la configuración de interfaz, la tabla de rutas, la caché/captura ARP y la captura del enlace. Esto no demuestra que el servicio aceptara la solicitud, que la VLAN no tuviera un puente adicional ni que la política IPv6 fuera equivalente.

Para sostenerlo, se necesitan al menos configuración efectiva, tabla de rutas, evidencia de la resolución de vecino y una observación en el punto de salida. Un resultado negativo debe demostrar capacidad de observación: «no se observó ARP para .40 en la interfaz I durante T» es defendible; «el host .40 nunca recibió un paquete» exige evidencia del segmento destino o del router. La confianza debe bajar si el equipo usa múltiples tablas, VRF, túneles, proxies o direcciones temporales.

Límites del modelo y síntesis

El modelo calcula fronteras de prefijo y explica decisiones de siguiente salto, pero no reconstruye por sí solo la topología física, la política de firewall, la identidad del proceso ni el estado de una aplicación. Una dirección puede ser válida y no alcanzable; una ruta puede existir y ser filtrada; un paquete puede llegar y ser rechazado; un prefijo puede agregarse y ocultar una frontera administrativa. Las implementaciones también añaden selección de dirección, métricas, VRF, políticas de routing, proxies y túneles que quedan fuera de este capítulo.

La transferencia profesional consiste en mantener juntas cinco piezas: valor binario y prefijo, semántica y ámbito, decisión de siguiente salto, evidencia en el punto observado y propiedad de seguridad que se pretende proteger. IPv4 e IPv6 comparten el razonamiento de prefijos y rutas, pero difieren en resolución de vecinos, multicast, configuración y fragmentación. Subnetting hace explícita una frontera matemática; sólo una política y controles efectivos pueden convertirla en una frontera de seguridad. El cálculo correcto es el comienzo del análisis, no su conclusión.