mpetach at netflight
May 6, 2012, 8:25 AM
Post #1 of 10
(348 views)
Permalink
|
|
What is a link-local address?? WAS: Re: JUNOS forwards IPv6 link-local packets
|
|
(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
|
