Subject: Link-local prefixes: A case in point

From: Peter Occil <[email-masked]>
Date: Fri, 21 Sep 2018 11:14:38 -0400

For your information, consider the following in the debate on whether link-local addresses should have a 10-bit or 64-bit prefix, or a prefix of some other length.

RFC 6874, "Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers", has the following to say in its security considerations.

   To limit this risk, implementations MUST NOT allow use of this format
   except for well-defined usages, such as sending to link-local
   addresses under prefix fe80::/10.  At the time of writing, this is
   the only well-defined usage known.

If a future RFC changes the prefix for link-local addresses from 10 bits to another length, then an erratum to RFC 6874 would be needed.  Perhaps the text “under prefix fe80::/10” could be deleted with or without such a future RFC.

--Peter

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 22 Sep 2018 08:38:17 +1200

> If a future RFC changes the prefix for link-local addresses from 10 bits to another length, then an erratum to RFC 6874 would be needed.  Perhaps the text “under prefix fe80::/10” could be deleted…

The addressing architecture is quite clear that everything under the /10 is
link-local, and I see no reason to change it. We included the second
sentence that you quoted to future-proof the text.

   Brian

---

From: Fred Baker <[email-masked]>
Date: Sat, 22 Sep 2018 12:03:12 -0700

> On Sep 21, 2018, at 1:38 PM, Brian E Carpenter <[email-masked]> wrote:
> 

It's at least worth noting history. The prefix was originally shared with site-local; if bits 10-64 were zero, it was link-local, and otherwise they were presumed to be a random number identifying the site the site-local pertained to (https://tools.ietf.org/html/rfc4291#section-2.5.7). Site-local was deprecated with RFC 3879. From my perspective, there is no ambiguity in the /64 associated with link-local - if bits 10-64 are not zero, you're not looking at link-local, you're looking at an instance of a deprecated address format.

---

From: Ole Troan <[email-masked]>
Date: Sat, 22 Sep 2018 21:38:08 +0200

> On 22 Sep 2018, at 21:03, Fred Baker <[email-masked]> wrote:
> 
> 
> 

To be perfectly correct site-locals used the next /10. FEC0::/10. 

Cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 23 Sep 2018 08:31:00 +1200

> To be perfectly correct site-locals used the next /10. FEC0::/10. 

Right, Fred's remark applies to fe80::/9 in fact.

I still seem to see DNS servers in fec0::/10 sometimes.

    Brian

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 23 Sep 2018 17:55:41 -0700

> On Sep 22, 2018, at 1:31 PM, Brian E Carpenter <[email-masked]> wrote:
> 

Certain well known legacy operating systems e.g. windows 7 still have recourse to well known v6 addressed name servers in their ipv6 configuration

fec:0:0:0:ffff::1 fec:0:0:0:ffff::2 fec:0:0:0:ffff::3

Which exactly illustrates why statically configured well known addresses are a terrible idea.

https://tools.ietf.org/html/draft-ietf-ipv6-dns-discovery-07

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

---

From: David Farmer <[email-masked]>
Date: Mon, 24 Sep 2018 10:20:29 -0500

On Sat, Sep 22, 2018 at 3:31 PM, Brian E Carpenter <
[email-masked]> wrote:

> >>>> For your information, consider the following in the debate on whether
> link-local addresses should have a 10-bit or 64-bit prefix, or a prefix of
> some other length.
> >>>>
> >>>> RFC 6874, "Representing IPv6 Zone Identifiers in Address Literals and
> Uniform Resource Identifiers", has the following to say in its security
> considerations.
> >>>>
> >>>> If a future RFC changes the prefix for link-local addresses from 10
> bits to another length, then an erratum to RFC 6874 would be needed.
> Perhaps the text “under prefix fe80::/10” could be deleted with or without
> such a future RFC.
> >>>
> >> It's at least worth noting history. The prefix was originally shared
> with site-local; if bits 10-64 were zero, it was link-local, and otherwise
> they were presumed to be a random number identifying the site the
> site-local pertained to (https://tools.ietf.org/html/rfc4291#section-2.5.7).
> Site-local was deprecated with RFC 3879. From my perspective, there is no
> ambiguity in the /64 associated with link-local - if bits 10-64 are not
> zero, you're not looking at link-local, you're looking at an instance of a
> deprecated address format.
> >

Section 2.5.6 of RFC 4291 seems quite clear that the Link-Local prefix is
fe80::/64. However, the entirety of fe80::/10 is reserved, meaning the rest
of the /10 is not available for other uses.  Note that the rest of f000::/4
not otherwise designated for a special purpose use could, in theory, be
released the RIRs for allocation as global unicast someday.

By the way, shouldn't fec0::/10 be listed is the IANA IPv6 Special Purpose
Address Registry, as site-local with a status of deprecated referencing
RFC3879? RFC3879 doesn't release fec0::/10 for allocation for some other
purpose, and I'm not aware of any other standards action doing so. RFC3879
deprecates fec0::/10 use by new implementations, but allows old
implementations to continue to use it, and suggest routers should continue
to not allow it to be routed on the Internet.  So, I believe that means it
still has a special purpose.

Thanks.
--
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================