(tl;dr -- IPv6 link-local definition is ambiguous and inconsistent across vendors) 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: 2.4. Address Type Identification The type of an IPv6 address is identified by the high-order bits of the address, as follows: Address type Binary prefix IPv6 notation Section ------------ ------------- ------------- ------- Link-Local unicast 1111111010 FE80::/10 2.5.6 Global Unicast (everything else) (from http://tools.ietf.org/html/rfc4291#section-2.4 ) 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 However, when we read section 2.5.6, we see a different definition: 2.5.6. Link-Local IPv6 Unicast Addresses Link-Local addresses are for use on a single link. Link-Local addresses have the following format: | 10 | | bits | 54 bits | 64 bits | +----------+-------------+---------------------+ |1111111010| 0 | interface ID | +----------+-------------+---------------------+ Link-Local addresses are designed to be used for addressing on a single link for purposes such as automatic address configuration, neighbor discovery, or when no routers are present. 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 ) That section indicates that *only* addresses out of fe80:0:0:0::/64 are valid link local addresses; that is, where the upper 64 bits are precisely 1111111010000000000000000000000000000000000000000000000000000000 (1111111010 followed by 54 0 bits). Is section 2.5.6 wrong? Should it have been written more like section 2.5.7, that specified the address as a prefix, followed by 54 bits of subnet ID? Or 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? 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 has potential implications on the types of filtering people may be assuming their router vendors are doing; and, with respect to the parent thread, when you talk about routers forwarding link-local packets, it would probably be good to verify with your vendors whether they take the sentence "Routers must not forward any packets with Link-Local source or destination addresses to other links." to apply to all of fe80::/10, or only to the more restrictive fe80::/64 specified in section 2.5.6. I will note that empirical testing shows that even different product lines from the same vendor show different behaviours, as though some engineers read section 2.5.6 in detail, and others simply read section 2.4, and skipped the fine print. So...operators...what do *you* think the correct definition is? And which way would you prefer your router vendors to read RFC4291? Do you prefer the loose definition from section 2.4, or do you prefer the stricter definition from section 2.5.6? Given that the RFC is ambiguous, and has been for the past six years, I'd tend to think the IETF doesn't really have a strong position one way or the other, and is leaving it up to us as operators to vote with our money, and give guidance to router vendors as to which definition we'd like them to follow. Personally, I know my vote is to go with section 2.4, rather than leave all the rest of fe80::/10 in an unusable grey state, where some devices treat it as global unicast, and others treat it as link-local. If we all standardize on the reading in 2.5.6, we leave the entire rest of the /10 fallow, with only one /64 usable from it. Which way do *you* vote? Thanks! Matt