6

RFC 4291 specifies that IPv6 link-local unicast addresses must have a high-order bit sequence of 1111111010, or fe80::/10. However, the same document specifies that the 54 bits following the first 10 bits are zeros:

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

Why isn't the link-local address format simply specified as fe80::/64?

Jivan Pal
  • 105
  • 4
Ted Quanstrom
  • 2,102
  • 13
  • 21

1 Answers1

10

Why isn't the link-local address format simply specified as FE80::/64?

Because that would leave the option open for using other, non link-local networks that start with fe80 as the first word. For example fe80:1:2:3::/64 would not be in fe80::/64, so theoretically could be used for something else, and that would be an undesired result.

It also leaves the possibility that the current 54 0 bits could be used for some enhancement of link-local addresses in the future. Basically, they are reserved bits. Often, protocols with reserved bits start using those bits to add functionality, later. For example, IPv6 multicast has scopes and flags, and there were originally two reserved flags, but one of those was used to add functionality to IPv6 multicast. Then, with only one reserved flag bit left, a later RFC expanded the number of flag bits to eight, even though only three flag bits are used.

Ron Maupin
  • 98,218
  • 26
  • 115
  • 191
  • "and that would be an undesired result." — The reader is left wondering why that is undesirable. It's not like IANA have already allocated any other ranges within fe80::/10, nor have they or the IETF actually explicitly stated that they intend to reserve such ranges, right? – Jivan Pal Aug 07 '23 at 17:18