On 5/6/12, Matthew Petach <[email protected]> wrote: > I'm curious about what people's perception of valid link-local > addresses is; that is, what specifically makes a valid link-local > address?
> The top portion of RFC 4291 lists the link-local prefix as: [snip] > Link-Local unicast 1111111010 FE80::/10 2.5.6 > Global Unicast (everything else) /10 is the link-local prefix. Every address in this /10 is part of the link-local prefix, and no IP address in this /10 is a valid global unicast address. > Thus, it would *seem* that an address such as > fe80:1:1:1::2/64 > when configured on an interface for its link-local address would > be a valid link-local address, as it falls within fe80::/10 This is in the the link-local prefix, but not a valid address, it doesn't follow the format of a link local address as noted by 2.5.6. [snip] > Routers must not forward any packets with Link-Local source or > destination addresses to other links. > (from http://tools.ietf.org/html/rfc4291#section-2.5.6 ) > did the authors really intend that most of fe80::/10 > remain unused, and *only* a single /64 at the very > start of fe80::/10 would be valid? The usage of the remainder of the /10 reserved for link local is unspecified.; It is conceivable but unlikely that uses might be defined in the future. > I ask this because I'm running into situations where > indeed it seems that some router vendors do literally > only treat fe80::/64 as link-local, and *all other addresses > out of fe80::/10 are treated as global unicast*. This is definitely erroneous, since fe80::/10 is excluded from the global unicast address range. Addresses outside the first /64 _might_ be valid link-local or not, whatever they are, they are definitely not valid global unicast addresses, and they fall within the link-local range: routers are required to not forward packets with a source or destination within the /10. > This has potential implications on the types of filtering > people may be assuming their router vendors are doing; When we are talking about security matters... it's definitely not safe to assume your vendor has implemented all the source/destination address filtering they should. Implement suitable testing to verify. -- -JH
