2026-06-03

Análisis PCAP de solicitud de vecinos y DAD de IPv6: detección de direcciones duplicadas, SLAAC, NA faltante y sin conectividad IPv6

Cómo analizar la detección de direcciones IPv6 duplicadas, solicitudes de vecinos, anuncios de vecinos, fallas de SLAAC, respuestas NA faltantes, direcciones IPv6 duplicadas y falta de conectividad IPv6 en capturas de paquetes.

Los fallos de IPv6 suelen comenzar antes que TCP, TLS, DNS o HTTP. Los usuarios buscan "captura de paquetes DAD IPv6", "Solicitud de vecino sin respuesta", "Anuncio de vecino faltante", "dirección IPv6 duplicada", "SLAAC no funciona" y "pcap sin conectividad IPv6" cuando un host tiene una dirección pero no puede comunicarse de manera confiable.

La cirugía PCAP es útil porque IPv6 Neighbor Discovery depende de pequeños intercambios ICMPv6 que son fáciles de eliminar por error. Los paquetes anteriores al fallo de la aplicación suelen explicarlo todo.

¿Qué hace papá?

La detección de direcciones duplicadas comprueba si una dirección IPv6 ya está en uso antes de asignarla a una interfaz. Durante DAD, el anfitrión envía una Solicitud de vecino para la dirección provisional.

Si otro nodo responde, la dirección está duplicada y no debe usarse. Si no se encuentra ningún duplicado, la dirección puede volverse utilizable.

Los buscadores a menudo ven sólo "dirección IPv6 provisional" o "dadfailed" en la salida del sistema operativo. El pcap puede mostrar la Solicitud de Vecino real y cualquier respuesta.

Solicitud de vecinos y publicidad de vecinos

La Solicitud de Vecino pregunta quién tiene una dirección IPv6. Respuestas del anuncio del vecino.

Evidencia de paquete común:

Solicitud de vecino ICMPv6.
Destino de multidifusión del nodo solicitado.
Dirección de destino.
La dirección de origen puede no especificarse durante DAD.
Respuesta de anuncio de vecino ICMPv6.
Opciones de dirección de capa de enlace.

Si se envían paquetes NS pero NA nunca regresa, el problema puede ser la accesibilidad L2, el filtrado de multidifusión, la política de firewall, el manejo de direcciones duplicadas o suposiciones incorrectas en el enlace.

Contexto de anuncio de enrutador y SLAAC

SLAAC se basa en los anuncios de enrutadores para aprender prefijos y banderas. DAD luego verifica la dirección generada.

Un seguimiento de inicio de IPv6 útil incluye:

Solicitud de enrutador.
Anuncio de enrutador.
Opción de información de prefijo.
Dirección generada.
Solicitud de Vecino PAPÁ.
Cualquier anuncio de vecino.
Opciones de DNS si es relevante.

Si solo captura la conexión TCP fallida posterior, la causa de la configuración automática puede ser invisible.

Síntomas de dirección duplicada

Los problemas de direcciones IPv6 duplicadas aparecen como:

La dirección sigue siendo provisional.
La dirección queda obsoleta o falló.
La conectividad funciona brevemente y luego falla.
La caché vecina cambia entre direcciones MAC.
Dos máquinas virtuales clonadas a partir de un conflicto de imagen.
Los contenedores reutilizan direcciones estables.
El enrutador registra la detección de duplicados.

Las capturas de paquetes pueden probar si otro nodo respondió a DAD o si el host creyó incorrectamente que existía un duplicado.

Anuncio de vecino desaparecido

Si un host envía NS para una puerta de enlace o par y no recibe NA, la conectividad de la aplicación falla.

Posibles causas:

El objetivo está desconectado.
VLAN incorrecta.
Filtrado de multidifusión.
El firewall bloquea ICMPv6.
Cambiar problema de espionaje.
Problema del puente del hipervisor.
En realidad, la dirección no está en el enlace.
El diseño NAT o proxy confunde el descubrimiento de vecinos.

El bloqueo de ICMPv6 a menudo interrumpe IPv6 de formas que parecen no tener relación.

Punto de captura y multidifusión

Neighbor Discovery utiliza mucho la multidifusión. El punto de captura importa.

Controlar:

¿La captura está en la interfaz correcta?
¿Ve fotogramas de multidifusión?
¿El puente VM pasa ICMPv6?
¿Están presentes las etiquetas VLAN?
¿Se está filtrando o convirtiendo la multidifusión Wi-Fi?
¿El espejo del interruptor captura ambas direcciones?

Las capturas unilaterales pueden hacer que NDP parezca roto cuando la captura está incompleta.

Diagnósticos de aplicación falsos

Las fallas de IPv6 NDP a menudo se diagnostican erróneamente como:

Problema de DNS.
Problema TLS.
Problema del servidor web.
TCP timeout.
Bloque de puertos de firewall.
Problema de enrutamiento VPN.

Estos pueden ser síntomas posteriores. Si la solicitud de vecino falla, es posible que el host nunca llegue al par en L2.

Lista de verificación de depuración

Utilice este flujo de trabajo:

Captura desde el inicio de la interfaz.
Preservar la solicitud y el anuncio del enrutador.
Encuentre la solicitud de vecino de DAD.
Verifique el destino de la dirección tentativa.
Busque anuncios de vecinos.
Verifique el destino de multidifusión del nodo solicitado.
Compare direcciones MAC en opciones.
Verifique la resolución del vecino de la puerta de enlace.
Verifique la VLAN y el punto de captura.
Conserve los paquetes NDP con el flujo de aplicación fallido.

Diagnóstico final

Las fallas de IPv6 DAD y de solicitud de vecinos ocurren antes de la capa de aplicación. La evidencia importante es la solicitud de vecino ICMPv6, el anuncio de vecino, el contexto de anuncio de enrutador, la entrega de multidifusión, las respuestas de direcciones duplicadas y la ubicación de captura.

La cirugía PCAP ayuda a mantener esos paquetes pequeños pero decisivos adjuntos al flujo fallido para que la "falta de conectividad IPv6" se convierta en un diagnóstico específico de DAD, SLAAC, NDP, firewall o L2.

Respuesta basada en paquetes para «Análisis PCAP de solicitud de vecinos y DAD de IPv6: detección de direcciones duplicadas, SLAAC, NA faltante y sin conectividad IPv6»

La respuesta directa es que una etiqueta del analizador o un mensaje de la aplicación no determina la causa. Empieza por punto de captura y dirección; demuestra la última frontera correcta y la primera fallida. En «Análisis PCAP de solicitud de vecinos y DAD de IPv6: detección de direcciones duplicadas, SLAAC, NA faltante y sin conectividad IPv6», otro revisor debe poder encontrar el packet, hueco o intervalo que sostiene cada frase y saber qué evidencia podría refutarla.

Situar la captura en el camino

Registra client, server y cualquier proxy, load balancer, NAT o firewall. Indica interface, lugar, reloj, sistema y direcciones visibles. Una captura junto al client demuestra lo que llegó allí, no que el server no enviara. Una junto al server demuestra salida en ese punto, no tránsito completo. Antes de comparar dos puntos corrige clock offset y alinea flow tuple, TCP sequence o transaction ID.

Comprueba calidad: snap length, dropped packets, offload, capture filter, ring buffer y hora inicial. Un checksum incorrecto en host puede ser offload artifact. Un segmento grande puede provenir de GRO/TSO y no existir así en el cable. Un packet ausente en un archivo limitado no es network loss hasta demostrar que el punto debía verlo.

Leer fronteras en orden

Frontera	Evidencia correcta	Evidencia de fallo
Link e IP	dirección, addresses y ruta coherentes	ARP/NDP ausente, ICMP, MTU, asimetría
TCP	SYN, SYN-ACK, ACK y sequence	retransmission, RST, zero window, timeout
TLS	ClientHello, ServerHello y progreso	alert o límite SNI/ALPN/certificate
Aplicación	request completo y response relacionado	status, gap o cierre temprano
Usuario	response time o failure window	stall ligado a una frontera

Detente en la primera frontera sin éxito. Si TCP no termina, no empieces por HTTP. Si request llega al proxy pero no al upstream, el límite está en proxy o su camino. Si llega al upstream sin response antes del timeout, usa ACK y progreso de bytes para separar application delay de network loss.

Separar observación e hipótesis

La observación se puede señalar: «Client envió hasta cierta sequence; sender repitió un segmento tres veces y no apareció ACK avanzado en este punto». La hipótesis es «el camino perdió el segmento». Otra captura o dropped records pueden refutarla. Para cada hipótesis escribe una prueba favorable y una contraria.

Retransmission o duplicate ACK no asigna culpable. Reordering, loss, capture artifact y receiver delay producen marcas similares. Relaciona dirección, sequence, ACK, SACK, RTT, window y tiempo de aplicación. En DNS o DHCP enlaza transaction ID, addresses e intentos; en HTTP, request y response; en TLS, dirección del handshake.

Preservar el original

Calcula checksum y conserva el original sin cambios. Filtra, recorta y redacta una working copy. Registra input, transformación, hora, packet count antes/después, checksum y motivo. Tras reescribir timestamps o eliminar packets, esa copia pierde capacidad para algunas conclusiones de tiempo o secuencia.

Sustituye addresses e identificadores de forma constante para seguir el mismo endpoint. No elimines ports, directions o lengths necesarios. Guarda aparte el mapa secreto. Revisa límites de captura y exportación y el flujo general de PCAP Surgery.

QA antes de publicar

¿Título y respuesta tratan el mismo flow? ¿Cada duración nombra reloj y puntos? ¿Está identificada la primera frontera fallida? ¿Existe explicación alternativa? ¿Se repite cambiando una variable? ¿Se conserva el original? Declara el límite: «Esta captura demuestra comportamiento junto al client durante este intervalo; no demuestra la ejecución interna del server».

Semrush no se distribuye por plantilla. El término validado PCAP analyzer pertenece solo a la página del producto; este artículo conserva su pregunta técnica y no inventa volumen ni KD.

Respuesta directa y límite de aceptación

La respuesta breve a «Análisis PCAP de solicitud de vecinos y DAD de IPv6: detección de direcciones duplicadas, SLAAC, NA faltante y sin conectividad IPv6» es: Cómo analizar la detección de direcciones IPv6 duplicadas, solicitudes de vecinos, anuncios de vecinos, fallas de SLAAC, respuestas NA faltantes, direcciones IPv6 duplicadas y falta de conectividad IPv6 en capturas de paquetes. Trate esa frase como un resultado que debe comprobarse, no como una promesa para cualquier entrada, dispositivo, proyecto o entorno. Un resultado completo registra estado inicial, acción exacta, salida visible y condición que demuestra que la tarea terminó en PCAP Surgery.

Procedimiento basado en evidencia

Empiece con un caso pequeño y repetible antes de cambiar un proyecto completo. Anote versión de la aplicación, sistema operativo, identidad de entrada o dispositivo, ajustes relevantes y resultado esperado. Ejecute una acción deliberada, conserve la primera transición inesperada y compárela con un caso conocido cuando exista. Cambiar varios controles a la vez oculta qué condición creó o corrigió el problema.

Punto de control 1: Análisis PCAP de solicitud de vecinos y DAD de IPv6: detección de direcciones duplicadas,

Si «Análisis PCAP de solicitud de vecinos y DAD de IPv6: detección de direcciones duplicadas, SLAAC, NA faltante y sin conectividad IPv6» es ambiguo, compare un caso bueno y otro fallido bajo condiciones equivalentes. Marque la primera diferencia significativa en vez de enumerar todos los síntomas posteriores. Ese límite suele producir una consulta más clara y un experimento más seguro.

Punto de control 2: Cómo analizar la detección de direcciones IPv6 duplicadas, solicitudes de vecinos, anuncio

Compruebe «Cómo analizar la detección de direcciones IPv6 duplicadas, solicitudes de vecinos, anuncios de vecinos, fallas de SLAAC, respuestas NA faltantes, dire» con la entrada representativa más pequeña. Mantenga iguales los ajustes no relacionados, repita la misma acción y revise el resultado después de reabrir o reconectar. Una captura aislada es más débil que un registro con entrada, ajuste, acción, salida y hora.

Punto de control 3: ¿Qué hace papá?

Si «¿Qué hace papá?» es ambiguo, compare un caso bueno y otro fallido bajo condiciones equivalentes. Marque la primera diferencia significativa en vez de enumerar todos los síntomas posteriores. Ese límite suele producir una consulta más clara y un experimento más seguro.

Punto de control 4: Solicitud de vecinos y publicidad de vecinos

Compruebe «Solicitud de vecinos y publicidad de vecinos» con la entrada representativa más pequeña. Mantenga iguales los ajustes no relacionados, repita la misma acción y revise el resultado después de reabrir o reconectar. Una captura aislada es más débil que un registro con entrada, ajuste, acción, salida y hora.

Punto de control 5: Contexto de anuncio de enrutador y SLAAC

Si «Contexto de anuncio de enrutador y SLAAC» es ambiguo, compare un caso bueno y otro fallido bajo condiciones equivalentes. Marque la primera diferencia significativa en vez de enumerar todos los síntomas posteriores. Ese límite suele producir una consulta más clara y un experimento más seguro.

Punto de control 6: Síntomas de dirección duplicada

Compruebe «Síntomas de dirección duplicada» con la entrada representativa más pequeña. Mantenga iguales los ajustes no relacionados, repita la misma acción y revise el resultado después de reabrir o reconectar. Una captura aislada es más débil que un registro con entrada, ajuste, acción, salida y hora.

Punto de control 7: Anuncio de vecino desaparecido

Si «Anuncio de vecino desaparecido» es ambiguo, compare un caso bueno y otro fallido bajo condiciones equivalentes. Marque la primera diferencia significativa en vez de enumerar todos los síntomas posteriores. Ese límite suele producir una consulta más clara y un experimento más seguro.

Punto de control 8: Punto de captura y multidifusión

Compruebe «Punto de captura y multidifusión» con la entrada representativa más pequeña. Mantenga iguales los ajustes no relacionados, repita la misma acción y revise el resultado después de reabrir o reconectar. Una captura aislada es más débil que un registro con entrada, ajuste, acción, salida y hora.

Punto de control 9: Diagnósticos de aplicación falsos

Si «Diagnósticos de aplicación falsos» es ambiguo, compare un caso bueno y otro fallido bajo condiciones equivalentes. Marque la primera diferencia significativa en vez de enumerar todos los síntomas posteriores. Ese límite suele producir una consulta más clara y un experimento más seguro.

Punto de control 10: Lista de verificación de depuración

Compruebe «Lista de verificación de depuración» con la entrada representativa más pequeña. Mantenga iguales los ajustes no relacionados, repita la misma acción y revise el resultado después de reabrir o reconectar. Una captura aislada es más débil que un registro con entrada, ajuste, acción, salida y hora.

Matriz de aceptación

Punto	Evidencia que conservar	Condición de aprobado
Análisis PCAP de solicitud de vecinos y DAD de IPv6: detección de direcciones duplicadas, SLAAC, NA faltante y sin conec	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Cómo analizar la detección de direcciones IPv6 duplicadas, solicitudes de vecinos, anuncios de vecinos, fallas de SLAAC,	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
¿Qué hace papá?	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Solicitud de vecinos y publicidad de vecinos	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Contexto de anuncio de enrutador y SLAAC	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Síntomas de dirección duplicada	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado

Aislamiento, recuperación y entrega

Deténgase en el primer límite que falla. Conserve fuente, proyecto, sesión o captura, duplíquelo antes de una edición destructiva y cambie una variable por experimento. Repetir un flujo amplio después de varios cambios puede dar otro resultado sin explicar la causa.

Separe ausencia de evidencia de evidencia de ausencia. Una vista vacía puede indicar entrada, alcance, filtro, permiso, dispositivo, intervalo o estado equivocado. Verifique adquisición o importación antes de interpretar el decoder, editor, informe o exportación.

Antes de entregar, reabra el artefacto y revise inicio, punto de decisión y final. Registre versión, plataforma, configuración, expectativa, observación y reproducción mínima. Elimine o redacte datos sensibles y confirme que el destinatario está autorizado.

Preguntas y respuestas

¿Cuál es la forma fiable más rápida de empezar?

Use el caso representativo más pequeño, escriba el resultado esperado y cambie una variable. Confirme el recorrido básico antes de añadir filtros, efectos, ediciones, automatización o una fuente mayor.

¿Qué evidencia debe guardarse?

Conserve identidad de entrada, versión, plataforma, ajustes, acción exacta, primera transición inesperada y salida final. Cierre y reabra cualquier proyecto, sesión, informe o exportación antes de considerarlo duradero.

¿Cuándo debe repetirse el procedimiento?

Repítalo después de cambios relevantes en aplicación, sistema, driver, firmware, modelo, fuente o flujo. Preserve el caso aceptado anterior como referencia sin modificar.

¿Cuándo está listo para entregar?

Cuando otra persona autorizada identifica la entrada, repite la acción, obtiene el mismo resultado, entiende los límites restantes y abre el artefacto sin depender de estado local no documentado.

Guías relacionadas

Estas páginas en el mismo idioma cubren etapas contiguas sin cambiar el propietario canónico del tema: