We are getting ping for the network IP in v6, which was not configured and not getting ND for the same.
We have checked the routes for this IP and no duplicates found.
Lab:
ACX7024 <-> MX204
ACX:
labroot@jtac-acx7024-dc-proto-r2002> show ipv6 neighbors
IPv6 Address Linklayer Address State Exp Rtr Secure Interface
2400:5200:a000::11:5400:23d 1c:9c:8c:19:4c:2b stale 834 yes no et-0/0/4.0
2400:5200:a000::11:5400:23f 1c:9c:8c:19:4c:2b stale 825 yes no et-0/0/4.0
fe80::1e9c:8cff:fe19:4c2b 1c:9c:8c:19:4c:2b stale 1129 yes no et-0/0/4.0
Total entries: 3
labroot@jtac-acx7024-dc-proto-r2002> ping 2400:5200:a000::11:5400:23c source 2400:5200:a000::11:5400:23e
PING 2400:5200:a000::11:5400:23c(2400:5200:a000::11:5400:23c) from 2400:5200:a000::11:5400:23e : 56 data bytes
64 bytes from 2400:5200:a000::11:5400:23c: icmp_seq=1 ttl=64 time=0.657 ms
64 bytes from 2400:5200:a000::11:5400:23c: icmp_seq=2 ttl=64 time=0.627 ms
labroot@jtac-acx7024-dc-proto-r2002> show configuration interfaces | display set
set interfaces et-0/0/4 unit 0 family inet address 182.19.115.1/30
set interfaces et-0/0/4 unit 0 family inet6 address 2400:5200:a000::11:5400:23e/126
MX:
labroot@jtac-mx204-r2015> show ipv6 neighbors
2400:5200:a000::11:5400:23e 74:e7:98:6d:43:20 stale 218 yes no xe-0/1/0.0
fe80::76e7:98ff:fe6d:4320 74:e7:98:6d:43:20 stale 336 yes no xe-0/1/0.0
Total entries: 2
labroot@jtac-mx204-r2015> ping 2400:5200:a000::11:5400:23c source 2400:5200:a000::11:5400:23d
PING6(56=40+8+8 bytes) 2400:5200:a000::11:5400:23d --> 2400:5200:a000::11:5400:23c
ping: sendmsg: Can't assign requested address
ping6: wrote 2400:5200:a000::11:5400:23c 16 chars, ret=-1
labroot@jtac-mx204-r2015> show configuration interfaces | display set
set interfaces xe-0/1/0 unit 0 family inet address 182.19.115.2/30
set interfaces xe-0/1/0 unit 0 family inet6 address 2400:5200:a000::11:5400:23f/126
set interfaces xe-0/1/0 unit 0 family inet6 address 2400:5200:a000::11:5400:23d/126
This issue is being fixed via PR1892000.
+++++++++++++++++++++++++++++++
It looks like a check to treat a RECV nexthop the same as a LOCL nexthop in the v6 packet path was added way back in this PR: 1295210
This check is not present in the IPv4 packet path, hence why this behaviour is only seen with IPv6 pings.
Since the correct behaviour is to drop the locally originated packet, it seems the solution would be to remove this check.