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

Mailman List Mirror (Read Only)
1

(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:

2

I would expect them to follow 2.4, even if the current spec says that
the 54 bits between /10 and /64 are supposed to be set to 0 today.
And indeed, it's the most pragmatic way to deal with that fuzzy spec.

Best regards,
Daniel

3

Any address withing FE80::/10 is a link local address, however when
you are constructing a link local address you sent bits [11..64]
to zero. It's quite common for a specification to only use a subset
of the reserved space which is what happens here.

Mark

4

Any address withing FE80::/10 is a link local address

said with great authority. shame the rfc does not do the same. matt
points out a spec and implementation problem.

randy

5

Zero is there to remove the "what do I set these bits to" problem
for auto configuration when you have the standard /64 net/host
split. The FE80::/10 is still clearly shown in 2.5.6 as a seperate
group of bits.

6

Once upon a time, Randy Bush <randy@psg.com> said:

> Any address withing FE80::/10 is a link local address

said with great authority. shame the rfc does not do the same. matt
points out a spec and implementation problem.

Well, the prefix length of 10 vs. 64 is hardly relevant when major
routers ignore the part about not forwarding the packets anyway.

7

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.

8

Hi Matthew,

Cisco routers forward packets for 127.0.0.0/8 unless explicitly
configured not to, treating it like any other unicast address.

Linux load balancers require a special kernel patch to also use them
as routers because the kernel authors failed to conceive of a
situation where accepting an external packet with a source address
matching a configured interface address was, in fact, a correct thing
to do.

I vote for the Cisco approach. It has occasionally quirky results but
it's also flexible enough to handle situations the protocol designers
didn't conceive of.

Regards,
Bill Herrin

9

Isn't it a simple scope violation in IPv6 and thus a bug and with that end of story?
I mean the check isn't even overly expensive in this case... and I can't see how much meaningful
other than unicast traffic passing a gateway you could do this way anyway. The worst
someone sends a small packet and you get a huge reply to a local node that didn't ask
for it keeping your switches and two random machines busy or generating a bit of nd noise,
or ...

19:12:31.257674 02:00:00:00:08:0b > 02:00:00:00:07:0a, ethertype IPv6 (0x86dd), length 70: (hlim 64, next-header ICMPv6 (58) payload length: 16) fe80::ff:fe00:80b > 2001:db8::1: [icmp6 sum ok] ICMP6, echo request, seq 12
19:12:31.257817 02:00:00:00:07:0a > 02:00:00:00:08:0b, ethertype IPv6 (0x86dd), length 118: (hlim 64, next-header ICMPv6 (58) payload length: 64) fe80::ff:fe00:70a > fe80::ff:fe00:80b: [icmp6 sum ok] ICMP6, destination unreachable, beyond scope 2001:db8::1, source address fe80::ff:fe00:80b

I actually tried to see if I could cross the atlantic with such a packet,
only to find that I didn't have an exist gateway showing this bug. Oh well,
I am safe.

/bz

10

The difference with IPv4, is the RFC1122 requirement is on hosts to
not allow the network number { 127, <any> } to appear outside the
host. There's no RFC requirement that a router refuse to forward
traffic with a source or destination address within the reserved
loopback network number. I a router filters based on source address
it is an added feature. there's no rfc requirement that an IPv4 router
"must not forward a packet with a source or destination address in the
[IPv4] loopback range". The Cisco behavior for 127/8 with IPv4
is therefore quite reasonable.

With IPv6, there is a RFC MUST requirement that such packets to the
link local address space not be forwarded, therefore that Cisco
behavior would be severely broken/ in IPv6 with regards to fe80::/10:
an IPv6 router must not forward such packets as would be allowed with
normal unicast addresses.

(Even if the router is configured with one of those addresses, locally)