Subject: SLAAC RFC4862 - appropriate length of fe80:: prefix

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 14 Sep 2018 15:57:04 +0200

In RFC4862 'SLAAC' there is text about an 'appropriate length' of the 
link-local prefix, and further pointing to RFC4291.

What is the 'appropriate length'?

Because otherwise it is hard to implement step 2, because it tells the 
bits after the ll prefix are set to 0.

>    A link-local address is formed by combining the well-known link-local
>     prefix FE80::0 [RFC4291 <https://tools.ietf.org/html/rfc4291>] (of appropriate length) with an interface
>     identifier as follows:
>
>     1.  The left-most 'prefix length' bits of the address are those of
>         the link-local prefix.
>
>     2.  The bits in the address to the right of the link-local prefix are
>         set to all zeroes.

Which are those bits?

>
>     3.  If the length of the interface identifier is N bits, the right-
>         most N bits of the address are replaced by the interface
>         identifier.

Alex

---

From: 神明達哉 <[email-masked]>
Date: Fri, 14 Sep 2018 09:41:55 -0700

At Fri, 14 Sep 2018 15:57:04 +0200,

> >     2.  The bits in the address to the right of the link-local prefix
are

The short answer would be:
- "the link-local prefix" is fe80::/10
- "the bits" in bullet #2 are the rightmost 118 bits

Somewhat longer answer, or explanation:

I guess a background motivation of the question is that RFC4291
doesn't explicitly define the term "link-local prefix".  While I
personally believe the specifications are sufficiently clear for the
vast majority of implementors, it would have been even more super
perfect if the description of RFC4862 referred to Section 2.4 of
RFC4291 and stated "the link-local prefix is the binary prefix shown
in Section 2.4 of RFC4291 that identifies link-local unicast
addresses".

In practice, if it were not fe80::/10, the only other possibility from
RFC4291 would be fe80::/64 according to this diagram:

   |   10     |
   |  bits    |         54 bits         |          64 bits           |
   +----------+-------------------------+----------------------------+
   |1111111010|           0             |       interface ID         |
   +----------+-------------------------+----------------------------+

Again, personally, I wouldn't consider the intermediate 54 bits to be
a part of the "link-local prefix", but since RFC4291 doesn't
explicitly define this term, I can't deny the possibility that someone
with extraordinary imagination could think that the 54 bits are part
of "the prefix".

Even with this interpretation, however, that doesn't matter much in
practice (at least today), since as of RFC4862 the length of the
interface ID is supposed to be defined in link-type documents, and
(AFAIK) all existing such documents say it's 64 bits.

So, either way, an implementation can auto-configure a link-local
address, and the result is the same.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 15 Sep 2018 08:30:12 +1200

Incidentally, this matches the terminology of draft-carpenter-6man-lap-01.
The Shortest Acceptable Identifier Length (SAIL) is 64 because
of SLAAC, and the Longest Acceptable Prefix (LAP) is 10. This
is made very clear by the diagram in RFC4291 section 2.5.6.
The inequality LAP + SAIL <= 128 is satisfied, and the bits in
the middle are zero by definition.

Regards
   Brian

On 2018-09-15 04:41, 神明達哉 wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 18 Sep 2018 13:34:03 +0200

Le 14/09/2018 à 18:41, 神明達哉 a écrit :
> Alexandre Petrescu <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>  > >     prefix FE80::0 [RFC4291 <https://tools.ietf.org/html/rfc4291>] 
> (of appropriate length) with an interface
>  > >     identifier as follows:
>  > >

Thus, an address is made of 3 parts (10bit of network prefix, 54 0 bits, 
and the 64bits of the Interface ID), not of 2 parts (network prefix, 
Interface ID).

The inner 54 0 bits have no name.  They are neither subnet prefix, nor 
Interface ID.

It is strange.

So I call them the 'no man's bits'.

> vast majority of implementors,

No, it is not clear.

It is not clear because there are two old RFCs that miss an '/10' next 
to the 'fe80::'.  That is not an coincidence.  The presumable 
explanation of the missing '/10' is one can not know what to put there 
next to 'fe80::'.

I dont know either, and I would like to know.

If it were up to me, I would set the fe80::/10 to be the network prefix 
of link-local addresses, in the 'IPv6 Addr Arch' document.  And have an 
Interface ID of length 118.

> it would have been even more super

It's still vague, because RFC4291 still lets one infer that there are no 
man's bits in the LL address. (it says IID must be 64).

>     |  bits    |         54 bits         |          64 bits           |

The 54 bits are the 'no man's bits'.

> (AFAIK) all existing such documents say it's 64 bits.

It works in practice.

If the no man's bits were part of the Interface ID then we could come up 
with a stronger privacy random IID.

If the no man's bits were part of the subnet prefix then we could 
clarify that the prefix is not /10 but /118 in other RFCs.

Making a decision about the no man's bits can only help.

> address, and the result is the same.

Yes, implementation works.

Alex

---

From: 神明達哉 <[email-masked]>
Date: Thu, 20 Sep 2018 11:57:37 -0700

At Tue, 18 Sep 2018 13:34:03 +0200,

> and the 64bits of the Interface ID), not of 2 parts (network prefix,

In this context the 10 bit prefix is not a "network prefix" but a
"link-local prefix" (to autoconfigure a link-local address), but other
than that, yes, it can consist of three parts if the interface
identifier is longer than 64 bits: the 10-bit link-local prefix,
intermediate bits, and the interface identifier.  I don't see RFC4862
says anything against it.

> The inner 54 0 bits have no name.  They are neither subnet prefix, nor

Correct, and I don't see the absolute need for it to have a name.
So...

> It is strange.

...I don't see what's strange.  There are many things that don't have
a name (e.g. as far as I know the intermediate 'ffff' 16 bits of
IPv4-mapped IPv6 addresses don't have a defined name), and I just see
this case as one of such things.  But if you have a particular problem
like interoperability failure due to the fact that these intermediate
bits aren't given a name, please feel free to write a draft to explain
the problem and how naming the bits solves the problem.  With some
energy and luck, it might eventually be published as an RFC and might
help someone else.

--
JINMEI, Tatuya

---

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

Le 20/09/2018 à 20:57, 神明達哉 a écrit :
>  > >  > In RFC4862 'SLAAC' there is text about an 'appropriate length' 
> of the
>  > >  > link-local prefix, and further pointing to RFC4291.
>  > >  >
>  > >  > What is the 'appropriate length'?
>  > >  >
>  > >  > Because otherwise it is hard to implement step 2, because it 
> tells the
>  > >  > bits after the ll prefix are set to 0.
>  > >  >
>  > >  > >    A link-local address is formed by combining the well-known
>  > > link-local
>  > >  > >     prefix FE80::0 [RFC4291 
> <https://tools.ietf.org/html/rfc4291>]
>  > >  > >     identifier as follows:
>  > >  > >
>  > >  > >     1.  The left-most 'prefix length' bits of the address are 
> those of
>  > >  > >         the link-local prefix.
>  > >  > >
>  > >  > >     2.  The bits in the address to the right of the link-local
>  > > prefix are
>  > >  > >         set to all zeroes.
>  > >  >
>  > >  > Which are those bits?
>  > >
> Correct, and I don't see the absolute need for it to have a name.`
> So...
> 
>  > It is strange.
> 
> IPv4-mapped IPv6 addresses don't have a defined name),

Arent these ffff addresses disappearing?  We no longer see them in Windows.

Same with the addresses that have ff:fe in the middle.  They didnt have 
a name either.

> and I just see
> bits aren't given a name,

I have a problem of waste.  It is little reasonable to put 54bits to 0 
always.

Alex

  please feel free to write a draft to explain

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 21 Sep 2018 13:24:30 +0200

[...]
> But if you have a particular problem like interoperability failure
> due to the fact that these intermediate bits aren't given a name,
> please feel free to write a draft to explain the problem and how
> naming the bits solves the problem.  With some energy and luck, it
> might eventually be published as an RFC and might help someone else.

I do not have an interoperability problem for fe80::/10 vs fe80::/64 at 
this time.

I have a problem of a (fictitious for now) implementation of RFC 7217 
'Stable and opaque IIDs for SLAAC'.

The problem is the following: RFC7217 needs the link-local prefix as 
input to a function that calculates the stable IID.  The link-local 
prefix is not specified in that RFC; the reader is referred to other 
RFCs that are themselves ambiguous and at times contradictory about the 
prefix length.  The output of the function will obviously change when 
the input changes from fe80::/10 or fe80::/64.  Only one of those two 
prefixes should be used.

A somehow related problem is that some linuces display fe80::/10 in 
their rt table, others fe80::/64.

To that end, I propose that I write a draft like the following:

------------------------------------------------------------------------
Title: The length of the IPv6 link-local prefix

Text: The length of the IPv6 subnet prefix with scope link is 64 
decimal.  This prefix is also known as link-local prefix, or link-scoped 
prefix.  The textual representation of this prefix is "fe80::/64".

Matter: [...]

IANA Considerations: IANA is requested to change the name of the column 
head in the table that depics the "Internet Protocol Version 6 Address 
Space".  The name should be "The first n bits of an address" instead of 
"IPv6 Prefix".
-------------------------------------------------------------------------

Alex
> -- JINMEI, Tatuya

---

From: Ole Troan <[email-masked]>
Date: Fri, 21 Sep 2018 14:08:18 +0200

> I have a problem of a (fictitious for now) implementation of RFC 7217 'Stable and opaque IIDs for SLAAC'.
> 
> The problem is the following: RFC7217 needs the link-local prefix as input to a function that calculates the stable IID.  The link-local prefix is not specified in that RFC; the reader is referred to other RFCs that are themselves ambiguous and at times contradictory about the prefix length.  The output of the function will obviously change when the input changes from fe80::/10 or fe80::/64.  Only one of those two prefixes should be used.

It doesn’t matter if you use fe80::/10 or fe80::/64 as input to the RFC7217 algorithm.
The calculation of the interface is local to the host. From an interoperability perspective it really doesn’t matter if you follow 7217 or not.
RFC7217 is of course useful in giving guidance for how to implement an interface-iid algorithm with the desired privacy and stability properties.

I would claim your problem will forever remain fictiious.

Cheers,
Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 21 Sep 2018 14:16:12 +0200

> It doesn’t matter if you use fe80::/10 or fe80::/64 as input to the RFC7217 algorithm.

?  10 or 64 is an input to that algorithm.

If it does not matter then why is it an input?

> RFC7217 is of course useful in giving guidance for how to implement an interface-iid algorithm with the desired privacy and stability properties.

?  But RFC 7217 is Standards Track, not just guidance.

Why do we have RFC 7217 in the first place if its parameters dont 
matter, its interop is not important, etc.

> I would claim your problem will forever remain fictiious.

:-) taken.

Alex

---

From: Ole Troan <[email-masked]>
Date: Fri, 21 Sep 2018 14:21:18 +0200

Alexandre,

> If it does not matter then why is it an input?

Because you want a stable iid that is dependent on the network prefix. FE80::/10 and FE80::/64 are both prefixes. So as long as you pick one consistently, you will get consistent results.

> Why do we have RFC 7217 in the first place if its parameters dont matter, its interop is not important, etc.

Because it is useful to give guidance to implementors and to have something to replace with EUI-64 with.

But that doesn’t mean that if you know what you are doing you are free to implement any other mechanism for IID generation that have the properties outlined in RFC7217.

Cheers,
Ole

---

From: Philip Homburg <[email-masked]>
Date: Fri, 21 Sep 2018 14:36:35 +0200

> Because you want a stable iid that is dependent on the network
> prefix. FE80::/10 and FE80::/64 are both prefixes. So as long as
> you pick one consistently, you will get consistent results.

It may be worth pointing out that mixing fe80::/10 and fe80::/64 on a single
link has a high risk of not working.

In many implementations, fe80::/64 is taken as a shorthand for:
- create addresses using fe80::/64 and SLAAC
- consider fe80::/64 to be onlink.

So a system that uses fe80::/10 and pseudo random IIDs may very well generate
an address that is not covered by the prefix fe80::/64. This will cause
systems that use fe80::/64 to consider that address offlink.

So for practical purposes, on ethernet-like networks, it is important to
use fe80::/64.

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 21 Sep 2018 14:41:48 +0200

This is a discussion about RFC7217

Le 21/09/2018 à 14:21, Ole Troan a écrit :
> Alexandre,
> 
>>>> I have a problem of a (fictitious for now) implementation of
>>>> RFC 7217 'Stable and opaque IIDs for SLAAC'.
>>>> 
>>>> The problem is the following: RFC7217 needs the link-local
>>>> prefix as input to a function that calculates the stable IID.
>>>> The link-local prefix is not specified in that RFC; the reader
>>>> is referred to other RFCs that are themselves ambiguous and at
>>>> times contradictory about the prefix length.  The output of the
>>>> function will obviously change when the input changes from
>>>> fe80::/10 or fe80::/64.  Only one of those two prefixes should
>>>> be used.
> prefix. FE80::/10 and FE80::/64 are both prefixes. So as long as you
> pick one consistently, you will get consistent results.

In this case I could have input 'cafe::/11' instead of 'fe80::/64', link 
it to the link-local part, and the RFC7217 algorithm would have worked 
equally well.

More: if none of the 4 parameters matter as input to the algorithm, I 
could have used one single number that is random.  I could have also 
used random MAC addresses, and not change the EUI-64 generation mechanism.

I do not understand, and I disagree, with such a heavy recommendation; 
(if it is as you say that the parameters dont matter.)

>>> The calculation of the interface is local to the host. From an
>>> interoperability perspective it really doesn’t matter if you
>>> follow 7217 or not. RFC7217 is of course useful in giving
>>> guidance for how to implement an interface-iid algorithm with the
>>> desired privacy and stability properties.
>> 

I fully agree that a replacement for EUI64-based-on-valid-MAC is necessary.

I also agree that guidance is often needed for implementer.

Yet I have now many doubts about the algorithm, as you suggest some 
parameters dont really matter.

> But that doesn’t mean that if you know what you are doing you are
> free to implement any other mechanism for IID generation that have
> the properties outlined in RFC7217.

These properties? RFC7217:
>   o  [IID] MUST be constant across system bootstrap sequences and other
>       network events (e.g., bringing another interface up or down).
 >
>    o  [IID] MUST be different for each network interface simultaneously in
>       use.
 >
> 
> Cheers, Ole
>

---

From: Ole Troan <[email-masked]>
Date: Fri, 21 Sep 2018 14:42:47 +0200

Philip,

> So for practical purposes, on ethernet-like networks, it is important to

This was purely in the context of IID generation.

From 7217:

The Interface Identifier is finally obtained by taking as many
       bits from the RID value (computed in the previous step) as
       necessary, starting from the least significant bit.

          We note that [
RFC4291
] requires that the Interface IDs of all
          unicast addresses (except those that start with the binary
          value 000) be 64 bits long.  However, the method discussed in
          this document could be employed for generating Interface IDs
          of any arbitrary length, albeit at the expense of reduced
          entropy (when employing Interface IDs smaller than 64 bits).

Ole

---

From: Ole Troan <[email-masked]>
Date: Fri, 21 Sep 2018 14:45:42 +0200

Alexandre,

> In this case I could have input 'cafe::/11' instead of 'fe80::/64', link it to the link-local part, and the RFC7217 algorithm would have worked equally well.
> 
> More: if none of the 4 parameters matter as input to the algorithm, I could have used one single number that is random.  I could have also used random MAC addresses, and not change the EUI-64 generation mechanism.
> 
> I do not understand, and I disagree, with such a heavy recommendation; (if it is as you say that the parameters dont matter.)

I never said the parameters don’t matter.
I said it doesn’t matter if you choose fe80::/10 or fe80::/64 as the prefix parameter to F().

Ole

---

From: Philip Homburg <[email-masked]>
Date: Fri, 21 Sep 2018 14:58:42 +0200

>This was purely in the context of IID generation.

I guess time to re-iterate my preference for keeping all IIDs for the purpose
of SLAAC at exactly 64 bits.

All flexibility that we allow in this area just generates all kinds of issues
down the road. If not implementation or operational issues, then issues for
people who try to read and understand the RFCs.

Like in this discussion. Even though in theory you could have fe80::/10 with a
118 bit IID. In practice, it has to be 64 bits.

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 21 Sep 2018 15:01:13 +0200

> I said it doesn’t matter if you choose fe80::/10 or fe80::/64 as the prefix parameter to F().

Since F() can not be inversed (SHA-256 with key is recommended), then if 
both 10 or 64 are fine as input then 65 is also fine as input.  They get 
mangled anyways.

Anyhow, one couldnt take the output of F and arrive back to 10, or to 64 
or to 65.

To achieve the intended goal (as I understand it: make an IID for 
link-local prefix, another IID for global prefix, etc) then one must 
save the _kind_ of address, not necessarily the fe80::/64, value prior 
to calculation; and then re-use same after an event like reboot.

For that to work, it is sufficient to use rand(), and save.  It is not 
necessary to use fe80::/64, nor fe80::/10, nor any other of the 4 
parameters described in the RFC (iface name and idx, ll address, service 
id).  I guess you wanted these in order to ensure different random 
numbers are generated at each generation moment, but that is already a 
characteristic of the random number generator.

(but I also agree that an implementation of this RFC has variable length 
IID, which is good).

Alex

---

From: Ole Troan <[email-masked]>
Date: Fri, 21 Sep 2018 15:04:36 +0200

Philip,

> 118 bit IID. In practice, it has to be 64 bits.

Again from 7217:
2.  The Interface Identifier is finally obtained by taking as many
       bits from the RID value (computed in the previous step) as
       necessary, starting from the least significant bit.

It doesn’t really matter if the algorithm takes 118 bits of IID combined it with fe80::/10 and sets bits 11-64 to 0, or takes 64 bits IID from the RID value and concatenates with fe80::/64.

You would still generate a valid link-local address.
And apologies if my text could be construed to imply I suggested one could use link-local addresses with bits 11-64 != 0. That would indeed lead to interoperability issues.

Cheers,
Ole

---

From: Philip Homburg <[email-masked]>
Date: Fri, 21 Sep 2018 15:28:54 +0200

>       necessary, starting from the least significant bit.

So instead of saying:
"Take the first 8 octets from the SHA-256 hash of ..." which would be
easy to understand for everybody,

We now have:
decide on a hash function that is not md5. Make sure the hash function is
actualy secure in this context. Now try to figure out where the least
significant bits are in the output of this hash function. Then figure out
how big the IID actually should be.

It doesn't buy us anything in the readability of RFCs.

---

From: Ole Troan <[email-masked]>
Date: Fri, 21 Sep 2018 15:36:51 +0200

Philip,

> It doesn't buy us anything in the readability of RFCs.

I don’t think anyone has suggested any changes to any RFCs at all. 

I had two points:
- with regards to Petrescu’s confusion. Whichever way he implemented it, he would reach the same end result. 
- if he wanted to roll his own iid generation algorithm in his implementation, he is of course free to do, without breaking interoperability. 

I don’t think there is anything to argue over, is there?

Cheers 
Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 21 Sep 2018 16:05:48 +0200

> I don’t think anyone has suggested any changes to any RFCs at all.

To that Request for Comments, I comment the following to RFC 'Opaque and 
Stable IIDs':
- use only one parameter, instead of four: a random number.
- use Mobile IPv6 to get Stable IPv6 addresses: Home Addresses.
- use EUI-64 based on randomly generated MAC addresses.
- other text clarifications ('computable' function).

Alex

---

From: 神明達哉 <[email-masked]>
Date: Fri, 21 Sep 2018 11:23:08 -0700

At Fri, 21 Sep 2018 14:45:42 +0200,

> I said it doesn’t matter if you choose fe80::/10 or fe80::/64 as the
prefix parameter to F().

You're right, of course.  But I also see a point that might be worth a
clarification in this discussion.

RFC7217 states:

       Prefix:
          The prefix to be used for SLAAC, as learned from an ICMPv6
          Router Advertisement message, or the link-local IPv6 unicast
          prefix [RFC4291].

Since "the prefix...as learned from an ICMPv6 Router Advertisement" is
obviously the subnet prefix (so the sum of prefix length and IID
length must be 128), it would be natural to consider "the link-local
IPv6 unicast prefix" as such, too.

But RFC 4291 itself doesn't explicitly define "the link-local IPv6
unicast prefix", and RFC 4821 states:

   A link-local address is formed by combining the well-known link-local
   prefix FE80::0 [RFC4291] (of appropriate length) with an interface
   identifier as follows:

where the "well-known link-local prefix" should actually mean
fe80::/10, which may not necessarily be a subnet prefix (and is indeed
not per the current addressing architecture).

So, an implementor who doesn't try to understand the higher level
context (which is, in this case, the consistency about the prefix
passed to F() instead of which prefix length to use) and is only
willing to interpret RFCs purely literally might be confused and think
they can't implement the spec.  In that sense, I see some value in
having a clarification document regarding "the unicast link-local
prefix".

p.s. I've quickly looked at draft-petrescu-6man-ll-prefix-len-00 and I
disagree with it; to me it's not correct if we simply say "the unicast
link-local prefix is fe80::/64".  IMO the clarification we might need is
that sometimes the "link-local prefix" is used to specify the
IANA-reserved address space for unicast link-local addresses
(fe80::/10), and sometimes it's used to mean the subnet prefix of
unicast link-local addresses (fe80::/64 as of RFC4291); it might also
help that the depending on the context the difference doesn't really
matter in practice (like the case of RFC7217) and sometimes it may be
distinguished more carefully (like when we use the prefix for on-link
determination).

--
JINMEI, Tatuya

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 24 Sep 2018 11:00:06 +0200

> link has a high risk of not working.

YEs, that is true.

A Cisco router does not reply the echo requests of a linux host if the 
router uses fe80:1::2 (plen 10).  But it would if the Cisco used fe80::2 
(plen 64).  The Host uses 64 by default.

That is an interoperability problem due to the length of the link-local 
prefix.

Alex

---

From: Ole Troan <[email-masked]>
Date: Mon, 24 Sep 2018 11:14:38 +0200

> A Cisco router does not reply the echo requests of a linux host if the router uses fe80:1::2 (plen 10).  But it would if the Cisco used fe80::2 (plen 64).  The Host uses 64 by default.
> 
> That is an interoperability problem due to the length of the link-local prefix.

It’s also an interoperability problem if you configured an ACL with deny any any on an interface.
This is a matter of how much rope you want to give the user.
Misconfiguration might of course lead to interoperability issues.

What’s your point?

Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 24 Sep 2018 11:39:39 +0200

> It’s also an interoperability problem if you configured an ACL with deny any any on an interface.

When typing 'deny any any' one understands very clearly 'deny all traffic'.

But when typing 'fe80:1::1' vs typing 'fe80::1' one has no clue whether 
10 or 64 will be derived out of that parameter.

Only if s/he types fe80::1 the router will interop with a linux (which 
uses default fe80::/64).

> Misconfiguration might of course lead to interoperability issues.

The point is to say there is an interop problem too because of two 
distinct possible prefix lengths for ll prefixes.

Alex