El problema principal en este caso no es el de seguridad en primer lugar; esta situación crea una pérdida aparente de paquetes, ya que la asignación del protocolo de la capa de enlace para su dirección IP cambiará normalmente entre usted y el otro nodo de acuerdo con la acción de una condición de carrera y gran parte del tráfico no irá al solicitante. Por supuesto, todo esto depende de la capa de enlace.
Es ciertamente posible que veas algo del tráfico del otro, y si fueras malicioso, ciertamente podrías volcarlo. Por supuesto, probablemente no obtendrías todo eso. Sin embargo, esto no es diferente de ver el tráfico en tránsito a través de un puerto espejo o sacarlo de un enrutador o algo así, por ejemplo, no haría más fácil romper la seguridad de las sesiones SSL. Entonces, incluso si esto sucediera (y esto indicaría una grave incompetencia por parte del ISP), no esperaría una violación real de la seguridad a menos que no estuviera cifrando las cosas.
También verías el tráfico de retorno de la otra persona, pero no lo que envían.
En la práctica, cuando hay direcciones IP duplicadas como esta en una red Ethernet y los nodos no detectan y manejan la falla, es básicamente imposible completar el protocolo de enlace de 3 vías TCP (y mucho menos negociar una sesión TLS) y la conexión parece ser extremadamente pobre o completamente deprimido.
La mayoría de las diferencias serían como resultado de la capa de enlace y cómo asigna las direcciones de capa de enlace a las direcciones de red, y la mayoría de las diferencias de seguridad dependerían del protocolo de capa de aplicación que se esté utilizando y de si IPsec está en uso. En IPv6, ya que se le asigna un prefijo y eso es lo que tendría que estar en conflicto, la consecuencia sería casi idéntica, excepto que no es probable que haya alguien en su red con la misma IP a la que están destinados los paquetes mal dirigidos.