What is a link-local address?? WAS: Re: JUNOS forwards IPv6 link-local packets

Jimmy Hess mysidia at gmail.com
Mon May 7 05:42:11 UTC 2012

On 5/6/12, Matthew Petach <mpetach at netflight.com> 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:
>       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.

>    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.


More information about the NANOG mailing list