[Bug 263288] IPv6 system not responding to Neighbor Solicitation

From: <bugzilla-noreply_at_freebsd.org>
Date: Tue, 26 Apr 2022 03:42:20 UTC

--- Comment #18 from Zhenlei Huang <zlei.huang@gmail.com> ---
(In reply to wcarson.bugzilla from comment #17)

> To be perfectly clear: 2600:3c00::/64 is shared insofar as other customers have VMs
> with IPv6 addresses on the same IPv6 subnet. Your SLAAC-assigned IPv6 address -
> 2600:3c00::f03c:91ff:feb0:a56f - is a /128 range, which essentially makes it a
> single IPv6 address which only your VM can use.

If other customers do NOT send spoofed NS packets, or your provider has means
to prevent spoofed NS packets, then it is safe to turn on

> The addresses within your /64 range - 2600:3c00:e000:0137::/64 - can only be used
> by the VM it's routed towards.

Since your provider provided routed /64 block, the upstream router should have
route to this /64 block, then the SLAAC-assigned IPv6 address
2600:3c00::f03c:91ff:feb0:a56f is not required, and you can use
2600:3c00:e000:0137::/64 directly. You can keep 'nd6_onlink_ns_rfc4861'
untouched and try this:

# ping6 -S 2600:3c00:e000:0137:cafe:8a2e:0370:7334 ipv6.google.com

or disable SLAAC:

# service rtsold stop
# ifconfig em0 inet6 -accept_rtadv
# ifconfig em0 inet6 2600:3c00::f03c:91ff:feb0:a56f delete
# route -6 get default || route -6 add default fe80::1%em0
# ping6 ipv6.google.com

You are receiving this mail because:
You are the assignee for the bug.