https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280390
--- Comment #24 from Tatsuki Makino <tatsuki_mak...@hotmail.com> --- (In reply to Andrey V. Elsukov from comment #22 & #23) > I still doesn't understand your problem. Me too :) As a result of being stingy with the money I pay upstream (removing services like phone and cable TV), the upstream provider only gives me a /64 prefix :) In this case, the terminal connected to the downstream interface cannot communicate with the upstream unless the downstream interface belongs to the same bridge as the upstream interface. By using NPTv6, it is possible to make it a layer 3 packet forward. However, since the upstream prefix is already /64, there can only be one /64 prefix available for use downstream. There are two interfaces downstream. It seems that bridging those two interfaces would work, but since it operates in a dual stack with IPv4 and dhcpd is also running, it causes issues with the operation. It was also tried to set a prefix length of /64+x on the interface when receiving a /64 RA from upstream via another patch. This method itself works pleasantly on FreeBSD. However, everything gets ruined because Andr○id refuses to operate with a prefix longer than /64. Wind○ws also requires that DHCPv6 is running when the prefix is longer than /64. And the keep-state rule was introduced to identify which prefix to choose when translating two or more downstream prefixes to the address of one upstream prefix and then returning it. Since NPTv6 has the same prefix length before and after translation, it seems that routing cannot return to the original interface, and this method must be used. I was considering what to do about the part you pointed out, as the dynamic rules for ICMPv6 require that the addresses on both ends match exactly. As you can see in my patch, normal ICMPv6 packets should have a port value of 0, so I feel that having a port that is not 0 can be interpreted differently :) In any case, there is no problem with NPTv6 itself. It seems that a person like me is just trying to use it in a strange way :) -- You are receiving this mail because: You are on the CC list for the bug.
