Subject: Question about the link-local addresses

From: "Yu Hua bing" <[email-masked]>
Date: Sat, 5 Mar 2011 10:59:25 +0800

>RFC4291
  > 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         |
   +----------+-------------------------+----------------------------+

I have a question: If the front 10 bits of one IPv6 address is FE80 and the middle 54 bits is not zero, is it link-local address?

---

From: Fred Baker <[email-masked]>
Date: Fri, 4 Mar 2011 21:42:13 -0800

>    |  bits    |         54 bits         |          64 bits           |

http://tools.ietf.org/html/rfc4291#section-2.5.6

> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Karl Auer <[email-masked]>
Date: Sat, 05 Mar 2011 17:14:22 +1100

On Fri, 2011-03-04 at 21:42 -0800, Fred Baker wrote:
> > I have a question: If the front 10 bits of one
> > IPv6 address is FE80 and the middle 54 bits is
> > not zero, is it link-local address?
> 

That section contains the exact text that Yu Hua bing quoted from the
RFC. I'm not sure that it answers his question. Does it?

My guess is that having any bits set in that 54-bit region makes an
address technically "not a link-local address". On the other hand, I
wonder how many implementations do more than check the first ten bits...

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([email-masked])                   +61-2-64957160 (h)
http://www.biplane.com.au/kauer/                   +61-428-957160 (mob)

GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156

---

From: "Yu Hua bing" <[email-masked]>
Date: Sat, 5 Mar 2011 20:11:51 +0800

According to RFC4291, it is not link-local address, but cisco and BSD think of it as link-local address.

From: Fred Baker 
Sent: Saturday, March 05, 2011 1:42 PM
To: Yu Hua bing 
Cc: [email-masked] 
Subject: Re: Question about the link-local addresses

     |   10     |

---

From: Scott Schmit <[email-masked]>
Date: Sat, 5 Mar 2011 09:49:54 -0500

>    |  bits    |         54 bits         |          64 bits           |

Increasing the puzzle, while the text above would imply that if the
middle 54 bits are not zero, it's not link-local, but if you look at
http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml,
you will see that IANA has allocated fe80::/10 to "Link Local Unicast".
This lends weight to the interpretation that it's the 10 bits that makes
it a link-local address. Otherwise, they should only have allocated
fe80::/64 for that purpose.

I'm leaning toward the interpretation being "if you're in fe80::/10,
you're link local, but addresses outside fe80::/64 are reserved."

-- 
Scott Schmit

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sat, 5 Mar 2011 09:27:50 -0600

Scott,

You are correct.  Note IANA assigns address blocks defined in some RFC
and indeed for the IPv6 link-local address RFC 4291 is referenced by
IANA.  See section 2.4 of RFC 4291 that includes this line.

[Link-Local unicast   1111111010           FE80::/10       2.5.6]

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Scott Schmit
Sent: Saturday, March 05, 2011 9:50 AM
To: [email-masked]
Subject: Re: Question about the link-local addresses

On Sat, Mar 05, 2011 at 10:59:25AM +0800, Yu Hua bing wrote ipv6:
> I have a question: If the front 10 bits of one IPv6 address is FE80
and the middle 54 bits is not zero, is it link-local address?

http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xm
l,

---

From: TJ <[email-masked]>
Date: Sat, 5 Mar 2011 10:31:52 -0500

On Mar 5, 2011 9:50 AM, "Scott Schmit" <[email-masked]> wrote:
> > I have a question: If the front 10 bits of one IPv6 address is FE80 and
the middle 54 bits is not zero, is it link-local address?
> you're link local, but addresses outside fe80::/64 are reserved."

Exactly right, IMHO.  Link local unicast (generic, that is - any link-scoped
uni) vs link local addresses (specific, the ones required* to be on an
interface)
/TJ

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 06 Mar 2011 08:40:40 +1300

Any router that forwards fe80::/10 would be pretty stupid I think,
since the whole prefix is IANA-reserved. The RFC apears to
only reserve fe80::/64.

Maybe this should be logged as a "held" erratum for RFC 4291,
to be made 100% clear if it is updated.

Regards
   Brian Carpenter

---

From: Brian Haberman <[email-masked]>
Date: Sat, 05 Mar 2011 15:11:41 -0500

> since the whole prefix is IANA-reserved. The RFC apears to

Actually, the IANA Considerations section of 4291 doesn't reserve 
anything.  But, 3513 does reserve FE80::/10 (as well as a bunch of other 
ranges).

> to be made 100% clear if it is updated.

There is a discrepancy between what is actually in 4291 and what is 
listed in the IANA table...

Regards,
Brian

---

From: Karl Auer <[email-masked]>
Date: Sun, 06 Mar 2011 09:28:06 +1100

> you're link local, but addresses outside fe80::/64 are reserved."

Linux treats link local addresses as being in a /64:

wlan0     [...]
          inet6 addr: fe80::222:fbff:fe54:9b80/64 Scope:Link
          [...]

While it may be that having bits set in that 54-bit region makes the
address technically not a link local address, I think in practice you
will see all addresses in fe80::/10 regarded as link local.

Regards, K.

---

From: Hagen Paul Pfeifer <[email-masked]>
Date: Sat, 5 Mar 2011 23:49:22 +0100

>          inet6 addr: fe80::222:fbff:fe54:9b80/64 Scope:Link

Yes (Linux):

if ((st & htonl(0xFFC00000)) == htonl(0xFE800000))
        return (IPV6_ADDR_LINKLOCAL | IPV6_ADDR_UNICAST |
                IPV6_ADDR_SCOPE_TYPE(IPV6_ADDR_SCOPE_LINKLOCAL)); 

as well as *BSD:

#define IN6_IS_ADDR_LINKLOCAL(a)        \
        (((a)->s6_addr[0] == 0xfe) && (((a)->s6_addr[1] & 0xc0) == 0x80))

Best regards, Hagen

---

From: Mark Smith <[email-masked]>
Date: Sun, 6 Mar 2011 09:26:53 +1030

On Sun, 06 Mar 2011 08:40:40 +1300

> to be made 100% clear if it is updated.

I've been a bit interested in this area fairly recently, in the context
of making things like RA guard a bit easier. If some of those 54 bits
were used to encode a device or function type, then RA guard could
be more simply achieved by filtering on link local source address
types e.g. if bits 11 through 16 in the link local prefix were used to
encode a type, then -

fe80::/16 - end-hosts
fe81::/16 - routers
fe82::/16 - dhcpv6 servers
etc.

This isn't a new idea, IIRC Appletalk used the lower 1-127 node
ids in a cable number for end-nodes, and the upper 128 to 253
for servers.

To see of non-fe80::/64 link locals would work with existing
implementations, I've run up a quick test with a couple of linux boxes,
with one running as a router (radvd, fe81::1/64, autoconf'd fe80::/64
deleted) and the other with a conventional kernel configured fe80::/64
link local address. Everything appears to be working, so it could be
possible to move to a link-local encoded type model without too much
trouble if other implementations handle non-fe80::/64 in the same way
(i.e. apparently as fe80::/10).

Regards,
Mark.

---

From: Fred Baker <[email-masked]>
Date: Sat, 5 Mar 2011 15:59:06 -0800

Dumb question. Is there an attack in your proposal? For example, if I were to mis-identify my RA as coming from an end-host, could I now bypass RA-Guard?

---

From: Mark Smith <[email-masked]>
Date: Sun, 6 Mar 2011 11:35:43 +1030

Hi Fred,

On Sat, 5 Mar 2011 15:59:06 -0800

> Dumb question. Is there an attack in your proposal? For example, if I were to mis-identify my RA as coming from an end-host, could I now bypass RA-Guard?

I'm not sure I fully understand your question, although I think you're
asking if end-nodes would also have to enforce this source
address/device function policy. That would be the case. My thoughts
around this area have mainly been related to the sort of effort layer 2
devices have to go to to inspect existing format RAs - encoding device
type/function in the source link local IPv6 address would seem to me
to be simpler, as the permit/deny decision it would be an exact match
on the first 10 bits of the source IPv6 address, almost directly after
the link-layer destination address in the frame, and that avoids these
layer 2 devices having to have knowledge of e.g. ICMPv6 formats, (maybe)
possibilities of extension headers etc. Possibly some devices which
can't implement RA guard as it is today might be able to perform a
simpler link-local source address based version. 

My interest in compatibility with existing link-local implementations
where RAs come from a non-fe80::/64 source was about how to easy a
transition to this sort of addressing model would be during an interim
period.

I haven't fully thought through my idea, including whether the cost of
this sort of change would be worth benefit, I mentioned it mainly
because it was relevant to the fe80::/10 vs fe80::/64 discussion.
Possibly there may be other benefits in encoding a device or function
type in a link-local address even if a simpler RA guard is not one of
them.

Regards,
Mark.

---

From: Brian Haberman <[email-masked]>
Date: Sun, 06 Mar 2011 08:56:49 -0500

> will see all addresses in fe80::/10 regarded as link local.

It is the FE80::/10 prefix that makes it link-local.  The FE80::/64 is
the currently documented formulation of a link-local unicast address
(and IANA properly reserves the FE80::/10 range).

Regards,
Brian