Subject: RFC 7217 - Prefix of LL

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 20 Sep 2018 11:38:24 +0200

RFC7217:

>        Prefix:
>            The prefix to be used for SLAAC, as learned from an ICMPv6
>            Router Advertisement message, or the link-local IPv6 unicast
>            prefix [RFC4291 <https://tools.ietf.org/html/rfc4291>].

What is the link-local IPv6 unicast prefix?  RFC4291 does not say 
clearly.  Sometimes it says fe80::/10 other times fe80::/64.  These two 
values lead to two different values of F(). We dont know which one is right.

Alex

---

From: Ole Troan <[email-masked]>
Date: Thu, 20 Sep 2018 12:24:20 +0200

>>           prefix [
>> RFC4291].
> What is the link-local IPv6 unicast prefix?  RFC4291 does not say clearly.  Sometimes it says fe80::/10 other times fe80::/64.  These two values lead to two different values of F(). We dont know which one is right.

https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml

It’s difficult to know if you are asking a real question, or just trying to make a point?

Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 20 Sep 2018 13:10:00 +0200

> It’s difficult to know if you are asking a real question, or just trying to make a point?

Both.

I think I was clear enough: the prefix length of LL addresses is 
unknown.  This has impact on how to write I-D.

What makes you think I am not clear enough?

Rather, I suspect you insist on continuing with the fe80::/10/64 ambiguity.

Because of this mistrust, I will stop here on this topic.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 20 Sep 2018 13:17:45 +0200

[...]

> fe80::/10 	Link-Scoped Unicast 	[RFC4291] 	Reserved by protocol. For authoritative registration, see [IANA registry iana-ipv6-special-registry].

RFC2464 says "prefix FE80::/64"
RFC4862 says "FE80::0 (of appropriate length)"
RFC4291 says "FE80::/10" and depicts a confusing FE80::/10/64/118

This is incoherent.

Alex

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

---

From: Morizot Timothy S <[email-masked]>
Date: Thu, 20 Sep 2018 12:11:49 +0000

> Alexandre Petrescu wrote:
> What is the link-local IPv6 unicast prefix?  RFC4291 does not say clearly.  Sometimes it says fe80::/10 other times fe80::/64.  These
> two values lead to two different values of F(). We dont know which one is right.
>
>

While it may not be written clearly, I haven't found the current definitions ambiguous. fe80::/10 is reserved at IANA for link local. That's one thing. Address blocks are often reserved and the space reserved can be more than is currently defined. RFC 4291 explicitly defines the following as a link local unicast address.

===========
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.

===============

The definition explicitly requires the 54 bits between the first 10 bits and the IID be set to the value of '0'. That means the defined prefix for a LL address in the current standard is fe80::/64. Since fe80::/10 is reserved, some devices (especially routers and switches) are designed to support configuration outside the currently defined /64 but endpoints expect a /64 and indeed have no way to discover a LL prefix with an unknown prefix. Reserving an address block for a specific purpose does not mean that the entire block has an explicitly defined use. But there's nothing ambiguous about the above LL definition. It explicitly defines how each bit of the entire 64 bit network prefix must be set. 

From RFC4291, here's a more generic definition.

=======

   A slightly sophisticated host (but still rather simple) may
   additionally be aware of subnet prefix(es) for the link(s) it is
   attached to, where different addresses may have different values for
   n:

   |          n bits               |           128-n bits            |
   +-------------------------------+---------------------------------+
   |       subnet prefix           |           interface ID          |
   +-------------------------------+---------------------------------+

==========

The IID is what's left after the subnet prefix. From that here's the global unicast definition.

==========

The general format for IPv6 Global Unicast addresses is as follows:

   |         n bits         |   m bits  |       128-n-m bits         |
   +------------------------+-----------+----------------------------+
   | global routing prefix  | subnet ID |       interface ID         |
   +------------------------+-----------+----------------------------+

===========

Though now deprecated, the original site local definition did not specify the 54 bits between the first 10 and the IID, though it did specify the IID as 64 bits.

===========

Site-Local addresses have the following format:

   |   10     |
   |  bits    |         54 bits         |         64 bits            |
   +----------+-------------------------+----------------------------+
   |1111111011|        subnet ID        |       interface ID         |
   +----------+-------------------------+----------------------------+

============

So again, in the current link local address definition the first 10 bits are explicitly defined. The next 54 bits are also explicitly defined as 0. And the remaining 64 bits form the IID. The currently defined link local address prefix is, by explicit definition, fe80::/64. The address block, fe80::/10 is reserved at IANA and additional uses can be defined within it. But I don't understand how you can call a definition that explicitly defines how every single one of the first 64 bits must be set ambiguous. How do you make a definition any clearer?

Scott

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 20 Sep 2018 14:56:48 +0200

You are asking me "How do you make a definition any clearer?"

Here is how: make RFC4291bis state that the link-local prefix is 
fe80::10 and that the Interface ID in the link-local prefix is of length 
118.

Do you agree?

See below the reason of why I propose that.

> While it may not be written clearly, I haven't found the current definitions ambiguous. fe80::/10 is reserved at IANA for link local. That's one thing. Address blocks are often reserved and the spa…

HAve you already programmed something with IPv6 identifiers?

Let us say you want to program the calculation of an opaque Interface ID 
RFC7217 and use the LL prefix as an input parameter.

Would you use fe80::/10 or fe80::/64 as input parameter?

You realize that depending on your choice, the output will change.  You 
also realize that you want the output to be predictable, not to be 'dont 
care', because if it were 'dont care' then you'd be happy with just 
calling rand() and no need of RFC7217 complications.

Alex

---

From: Morizot Timothy S <[email-masked]>
Date: Thu, 20 Sep 2018 13:14:13 +0000

> Alexandre Petrescu [mailto:[email-masked]]
> 

No, I do not agree because I know for certain that such a massive change in definition will break existing implementations. And I know that from practical experience.

A number of years ago, we had someone who saw the fe80::/10 reserved block and configured different explicit link locals outside fe80::/64 in a highly secured, entirely statically configured set of VLANs. Cisco switches will accept such a configuration, which is reasonable for a router/switch implementation in case additional uses in the reserved block are later defined. There were devices on those networks, with statically configured global unicast addresses, that kept losing network connectivity because they could not establish and maintain an entry in the neighbor table. They only knew how to configure a LL unicast address according to the RFC4291 explicit definition.

We hobbled along by statically adding the entry to the neighbor table on the switches, which was undesirable since the devices had interfaces bonded active/passive and the entry would have to be manually changed if the entry changed. I had to walk through RFC4291 and correct my colleague's misunderstanding of the definition. The end nodes had correctly implemented their LL according to the current definition. And indeed, nodes have to know on what prefix they will find link information. There is no equivalent to IPv4 broadcast which simply spams information to any device listening within L2 scope without regard for the network definition.

So changing the LL unicast definition at this juncture absolutely will break existing implementations. That should be avoided unless a way to implement a new definition without breaking implementations of the existing definition can also be clearly defined.

Scott

---

From: Morizot Timothy S <[email-masked]>
Date: Thu, 20 Sep 2018 13:20:30 +0000

> Morizot, Timothy S. wrote:
> So changing the LL unicast definition at this juncture absolutely will break existing implementations. That should be avoided unless a
> way to implement a new definition without breaking implementations of the existing definition can also be clearly defined.

Moreover, a change in the standard of that scale and impact absolutely should not be done as part of the process of moving a proposed standard to internet standard. Changing the explicit definition of the LL unicast address prefix and IID length qualifies as a major change in the standard from my perspective.

Scott

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 20 Sep 2018 15:26:12 +0200

Le 20/09/2018 à 15:20, Morizot Timothy S a écrit :
>> Morizot, Timothy S. wrote: So changing the LL unicast definition at
>> this juncture absolutely will break existing implementations. That
>> should be avoided unless a way to implement a new definition
>> without breaking implementations of the existing definition can
>> also be clearly defined.
> 
> Moreover, a change in the standard of that scale and impact
> absolutely should not be done as part of the process of moving a
> proposed standard to internet standard. Changing the explicit
> definition of the LL unicast address prefix and IID length qualifies
> as a major change in the standard from my perspective.

ifconfig add fe80::1/10 on a linux and nothing breaks.

Have you tried?

Alex

---

From: Morizot Timothy S <[email-masked]>
Date: Thu, 20 Sep 2018 14:00:39 +0000

> ifconfig add fe80::1/10 on a linux and nothing breaks.

Did you read my description of an actual production problem we encountered because a colleague misread the existing LL unicast definition precisely the same way you have and configured LL addresses on the layer 3 switches outside the RFC4291 draft standard defined fe80::/64 prefix? (Actually, he didn't really misread the definition. He just saw that fe80::/10 was the reserved address block, assumed that was the LL unicast definition, and was able to configure it on the layer 3 switches and routers. After we had lived with the problem for a while and encountered multiple problems with the static neighbor table entry workaround, I walked through the standard and found the detailed, explicit link local unicast definition in RFC4291. It's completely unambiguous. He still wanted to manually define the IID of the different network devices, but changing that definition to one that conformed to the definition resolved the problem we were experiencing. Since the definition is absolutely explicit, it was not a problem with the node implementation. The expectation that the link would be using fe80::/64 for link communication and ability to only configure a LL unicast address according to that definition was a reasonable implementation of the existing standard.)

That was not a hypothetical scenario and the linux implementation of LL is irrelevant to it. Moreover, a node has to know the LL prefix when it connects to the network for all the link communication to work properly. Yes, an explicit definition of 118 bits for the IID would have been as good a definition, I guess, as the existing 64 bit definition. But that's not what was chosen at the time. My point is that it is a major change in the current definition that will break existing implementations of the standard. I don't believe that's acceptable without some sort of clearly defined mechanism to transition from the current definition to the new one. Moreover, are changes on that scale to something that fundamental to the protocol normally a part of the process of moving a proposed standard to internet standard?

I'm not especially wedded to any LL unicast IID length. For the most part I can't think of a reason I really care one way or another. But changing the long-established defined IID length of 64 bits with an explicit fe80::/64 prefix will break things. Again, that's not a hypothetical. I have practical experience with at least one implementation it will break.

Scott

---

From: Morizot Timothy S <[email-masked]>
Date: Thu, 20 Sep 2018 14:14:14 +0000

> Morizot Timothy S wrote:
> I'm not especially wedded to any LL unicast IID length. For the most part I can't think of a reason I really care one way or another. But
> changing the long-established defined IID length of 64 bits with an explicit fe80::/64 prefix will break things. Again, that's not a
> hypothetical. I have practical experience with at least one implementation it will break.

Or to be precise, an implementation that a change like that would have broken back in the 2011-2013 timeframe. Obviously, there have been multiple changes both on the network device operating system side and on the node operating system side since then. I have no idea what the result of that configuration would be even with those specific devices today. But I know for certain that using anything other than an fe80::/64 prefix, as defined for link local unicast addresses in RFC 4291, broke things at that time in at least one implementation of the standard. And altering the LL unicast address definition seems like a very significant change to the standard to me.

Scott

---

From: Morizot Timothy S <[email-masked]>
Date: Thu, 20 Sep 2018 14:35:20 +0000

Morizot Timothy S wrote:
> But I know for certain that using
> anything other than an fe80::/64 prefix, as defined for link local unicast addresses in RFC 4291, broke things at that time in at least one
> implementation of the standard. And altering the LL unicast address definition seems like a very significant change to the standard to
> me.

And going back to RFC4291, there's nothing ambiguous about the link local IPv6 address definition itself. I've included it again below. The value of every one of the first 64 bits is explicitly defined and the length of the IID is also explicitly defined. The explicit definition of the first 64 bits *is* fe80::/64. Now, if it's confusing that the definition section doesn't also express the prefix using the fe80::/64 notation despite explicitly defining precisely that prefix, that should be added to the text of the definition. That would be a useful clarification of the existing standard text. Perhaps a single explanatory sentence could be added after the explicit definition of the bits. Something like: "Link-Local addresses are constructed using an fe80::/64 prefix and a 64 bit interface ID." A sentence like that would express the bit definition in descriptive language. I find the definition of the bits perfectly clear and explicit, but perhaps that clarification would be a helpful one. (I'm not necessarily the best at wordsmithing, so take that more as an example of a clarifying sentence than an actual suggestion for the text.) That would clarify the existing standard definition without dramatically altering it.

=================

   |   10     |

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 20 Sep 2018 17:14:07 +0200

Le 20/09/2018 à 16:35, Morizot Timothy S a écrit :
[...]
> "Link-Local addresses are constructed using an fe80::/64 prefix and a
> 64 bit interface ID."

If we go that way in RFC4291bis, then
- substitute fe80::/64 for fe80::/10 at IANA page.
- substitute "64" for "appropriate length" in RFC4862.
- add fe80::/64 in RFC7217.

Make it issue a syntax error when typing "ifconfig eth0 add fe80::1/10".

Alex

  A sentence like that would express the bit
> definition in descriptive language. I find the definition of the bits
> perfectly clear and explicit, but perhaps that clarification would be
> a helpful one. (I'm not necessarily the best at wordsmithing, so
> take that more as an example of a clarifying sentence than an actual 
> suggestion for the text.) That would clarify the existing standard 
> definition without dramatically altering it.
> 
> =================
> 
> 
> |   10     | |  bits    |         54 bits         |          64 bits
>  |

---

From: Morizot Timothy S <[email-masked]>
Date: Thu, 20 Sep 2018 15:35:10 +0000

> - add fe80::/64 in RFC7217.

I think there can be a legitimate argument for reserving the entire fe80::/10 address block for link local use even if there are no immediate plans to define additional uses. Reserving space for future use seems perfectly reasonable to me whether or not such future uses ever materialize. So I'm not sure there's a reason to alter the reserved block at IANA. I may misunderstand what IANA does and what the published information means, but I thought in this context they published the address blocks that were reserved for explicit purposes by standards.

> Make it issue a syntax error when typing "ifconfig eth0 add fe80::1/10".

I also have no opinion on whether or not a specific implementation should return a syntax error. There can also be an argument that devices which can be implemented basically as layer 3 routers include the flexibility to configure non-standard uses as long as they are within the reserved block. That implementation level flexibility can make it easier to try potential future uses or changes to the standard.

The current state does not bother me the way altering the actual standard link local unicast definition itself does. 

Scott

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 20 Sep 2018 21:04:40 +0200

Le 20/09/2018 à 17:35, Morizot Timothy S a écrit :
> Alexandre Petrescu:
>> If we go that way in RFC4291bis, then - substitute fe80::/64 for
>> fe80::/10 at IANA page. - substitute "64" for "appropriate length"
>> in RFC4862. - add fe80::/64 in RFC7217.
> 
> I think there can be a legitimate argument for reserving the entire
> fe80::/10 address block for link local use even if there are no
> immediate plans to define additional uses. Reserving space for future
> use seems perfectly reasonable to me whether or not such future uses
> ever materialize.

If IANA keeps the 54 bits beyond /10 for some future use then, one day 
maybe it will allocate fe80:1::/32 for 'special' link-local addresses, 
and so interface IDs other than 64 should be possible too.

I can not understand that.

However one turns it it does not fit.

Alex

  So I'm not sure there's a reason to alter the
> reserved block at IANA. I may misunderstand what IANA does and what
> the published information means, but I thought in this context they
> published the address blocks that were reserved for explicit purposes
> by standards.
> 
> I also have no opinion on whether or not a specific implementation
> should return a syntax error. There can also be an argument that
> devices which can be implemented basically as layer 3 routers include
> the flexibility to configure non-standard uses as long as they are
> within the reserved block. That implementation level flexibility can
> make it easier to try potential future uses or changes to the
> standard.
> 
> The current state does not bother me the way altering the actual
> standard link local unicast definition itself does.
> 
> Scott
>

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Thu, 20 Sep 2018 19:16:03 +0000

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Alexandre Petrescu

> If IANA keeps the 54 bits beyond /10 for some future use then, one
> day maybe it will allocate fe80:1::/32 for 'special' link-local
> addresses, and so interface IDs other than 64 should be possible too.

I don’t see the controversy here. The IETF tells the IANA to reserve this one /10 for link-local. Done.

Now the IETF has 64-bits of prefix to use for link-local, in which to date, 54 bits are set to 0 (unused). The IETF could easily decide, in the future, to use those 54 bits, even for just link-local, just as it did for ULAs.

As far as the IETF *and the hosts* are concerned, there is no implication anywhere that the IID is anything but 64 bits, for link-local. Logically, from the host's point of view, the prefix is 64 bits, the IID is 64 bits. They do have to add to 128 bits, after all.

The only organization that thinks of this as a 10-bit prefix ought to be the IANA.

Bert

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 21 Sep 2018 06:43:40 +0200

> I don’t see the controversy here. The IETF tells the IANA to reserve this one /10 for link-local. Done.

IANA reserves /10 and LLs are /64.

That saves a /11 or something like that, for future use.  Will the 
addresses still be /64 at that future use?

Alex

---

From: Sander Steffann <[email-masked]>
Date: Fri, 21 Sep 2018 12:07:27 +0200

Hi,

> That saves a /11 or something like that, for future use.  Will the addresses still be /64 at that future use?

Outside fe80::/64? Who knows?! Crystal balls welcome :)

Cheers,
Sander

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 24 Sep 2018 10:49:12 +0200

Le 20/09/2018 à 16:00, Morizot Timothy S a écrit :
> Alexandre Petrescu:
>> Le 20/09/2018 à 15:20, Morizot Timothy S a écrit : ifconfig add
>> fe80::1/10 on a linux and nothing breaks.
>> 
>> Have you tried?
> 
> Did you read my description of an actual production problem we
> encountered because a colleague misread the existing LL unicast
> definition precisely the same way you have and configured LL
> addresses on the layer 3 switches outside the RFC4291 draft standard
> defined fe80::/64 prefix? (Actually, he didn't really misread the
> definition. He just saw that fe80::/10 was the reserved address
> block, assumed that was the LL unicast definition, and was able to
> configure it on the layer 3 switches and routers.

In defence of your colleague:

He did not misread the definition of link-local prefix.

He just typed '?' on the command line of Cisco IOS.  He saw that he 
could add a link-local address of the form
'X:X:X:X::X'.

Anybody would interpret that as something like
'fe80:1:2:3::4'
and not like
'fe80::1234'.

In all rightness, the programmer did the former, and the OS added a 
prefix of length 10, not 64.

I am saying that because of this: the user manual of Cisco IOS 
explicitely says LL prefix is 10, and not 64.  And, there is no CLI to 
see the prefix that the OS has chosen to use after you typed a command 
to add an adress on the command line (no visible plen on the interface, 
nor on the rt table).  You can only find the LL prefix length by trial 
of other things.

Disclaimer: I do not have access to IOS source code.

Alex

  After we had lived
> with the problem for a while and encountered multiple problems with
> the static neighbor table entry workaround, I walked through the
> standard and found the detailed, explicit link local unicast
> definition in RFC4291. It's completely unambiguous. He still wanted
> to manually define the IID of the different network devices, but
> changing that definition to one that conformed to the definition
> resolved the problem we were experiencing. Since the definition is
> absolutely explicit, it was not a problem with the node
> implementation. The expectation that the link would be using
> fe80::/64 for link communication and ability to only configure a LL
> unicast address according to that definition was a reasonable
> implementation of the existing standard.)
> 
> That was not a hypothetical scenario and the linux implementation of
> LL is irrelevant to it. Moreover, a node has to know the LL prefix
> when it connects to the network for all the link communication to
> work properly. Yes, an explicit definition of 118 bits for the IID
> would have been as good a definition, I guess, as the existing 64 bit
> definition. But that's not what was chosen at the time. My point is
> that it is a major change in the current definition that will break
> existing implementations of the standard. I don't believe that's
> acceptable without some sort of clearly defined mechanism to
> transition from the current definition to the new one. Moreover, are
> changes on that scale to something that fundamental to the protocol
> normally a part of the process of moving a proposed standard to
> internet standard?
> 
> I'm not especially wedded to any LL unicast IID length. For the most
> part I can't think of a reason I really care one way or another. But
> changing the long-established defined IID length of 64 bits with an
> explicit fe80::/64 prefix will break things. Again, that's not a

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 24 Sep 2018 10:50:38 +0200

Le 20/09/2018 à 16:14, Morizot Timothy S a écrit :
> Or to be precise, an implementation that a change like that would have broken back in the 2011-2013 timeframe.

It is valid today.

Check the IOS documentation of ll prefix length you will see it says 10.

Alex

  Obviously, there have been multiple changes both on the network device 
operating system side and on the node operating system side since then. 
I have no idea what the result of that configuration would be even with 
those specific devices today. But I know for certain that using anything 
other than an fe80::/64 prefix, as defined for link local unicast 
addresses in RFC 4291, broke things at that time in at least one 
implementation of the standard. And altering the LL unicast address 
definition seems like a very significant change to the standard to me.