Huh? Please read what I said. I literally mentioned RFC 4291 Section 2.5.6. Additionally, fe80::/10 _is_ defined by RFC 4291 Section 2.4 as "Link-Local unicast" addresses. Section 2.5.6 does not redefine that but instead states that, at least as of now, only fe80::/64 is allowed to be used. The point of defining fe80::/10 as link-local despite only a portion of it being allowed to be used is to prevent other addresses in that block from being used for other purposes. I don't want this to devolve into a game of "Can you guess what RFC 4291 says?" though as I don't actually think it is relevant.
route(8) and perhaps other areas of the OS/kernel appear to force the second octet pair to be 0 which may or may not be the cause of my "ndp info overwritten" messages. If you are trying to imply that all fe80::/10 addresses are interpreted as fe80::/64 addresses, then even that does not make sense since you can clearly see that it is only the _second_ octet pair that has 0 while the other octet pairs retain the values that were passed.
