Subject: RFC8064 'stable IIDs' - for LLs

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

Hi,

In RFC8064 'stable IIDs' are recommended to be used for SLAAC.

But does this include the part of SLAAC that generates link-local addresses?

I am asking because the part of SLAAC that generates link-local 
addresses is not clear on the prefix length.

As such, I am tempted to believe RFC8064 does not apply to link-local 
addresses and other methods to achieve the same could be better, e.g. 
dynamically changing a MAC address.

Alex

---

From: Christian Huitema <[email-masked]>
Date: Fri, 14 Sep 2018 08:14:48 -0700

The stable IID algorithm is fine but if you want privacy you have to ensure that the IID gets randomized whenever you randomize the MAC.

-- Christian Huitema 

> On Sep 14, 2018, at 7:01 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> Hi,
> 
> I am asking because the part of SLAAC that generates link-local addresses is not clear on the prefix length.
> 
> As such, I am tempted to believe RFC8064 does not apply to link-local addresses and other methods to achieve the same could be better, e.g. dynamically changing a MAC address.
> 
> Alex
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

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

> addresses is not clear on the prefix length.

As noted on the other thread, RFC4291 is 100% clear on the identifier
length, which is what matters for your question.

I haven't bothered to check on Linux, but the Windows implementors
clearly decided to use the same IID for LL and stable GUAs. 

    Brian

---

From: Mark Smith <[email-masked]>
Date: Sat, 15 Sep 2018 07:48:10 +1000

> But does this include the part of SLAAC that generates link-local addresses?

Yes, RFC7217, which it specifies to use, specifically says

"The method specified in this document applies to all prefixes a host may
   be employing, including link-local, global, and unique-local prefixes
   (and their corresponding addresses)."

and here it is called out in the algorithm parameters:

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

Regards,
Mark.

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 18 Sep 2018 15:12:08 +0200

> length, which is what matters for your question.

Sorry, what do you mean it is clear?

Do you mean that the interface length is 64?

If yes, and the length of the link-local prefix is 10, then the 
intermediary 54 0 bits are called what?

Alex

---

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

>            Router Advertisement message, or the link-local IPv6 unicast

What is called the intermediary 54 0 bits in the link-local IPv6 unicast 
  prefix?

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Sep 2018 08:21:24 +1200

> Do you mean that the interface length is 64?

Yes. That is explicit in the diagram.

> intermediary 54 0 bits are called what?

They don't have a name. Why do they need a name?

   Brian

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Tue, 18 Sep 2018 20:57:29 +0000

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Brian E Carpenter

> They don't have a name. Why do they need a name?

In my personal interpretation of reality, those 0 bits are all prefix bits, but they happen to be unused for this one application. On the other hand, say for something like ULAs, those bits are put to good use - as the prefix bits they are meant to be.

Bert

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 19 Sep 2018 11:29:23 +0200

> They don't have a name. Why do they need a name?

To make people understand each other when talking same thing, and 
programmers to implement smoothly.

If the 54 0 bits DONT have a name then:
- they are not used, it is a waste at transmission.  can be compressed.
- could be part of IID [so IID MAY be something else than 64, contrary
   to belief].
- could be part of prefix [so plen is not /10, contrary to belief].
- RFC 2464 'IP-over-Ethernet' can continue to say
   'prefix fe80::/64' [wrong, it's /10]
- RFC 4862 'SLAAC' can continue to say
   'prefix FE80::0 of appropriate length'
   [wrong, it's precisely /10].

Of further concern to me is that it means that in the IPv6-over-OCB 
Internet Draft under writing, we continue to say:
  'If the IPv6 link-local address is formed using an EUI-64 identifier,
   then the mechanism of forming that address is the same mechanism as
   used to form an IPv6 link-local address on Ethernet links.  This
   mechanism is described in section 5 of [RFC2464].'
[it's wrong, because of referring to a losely defined rfc2464 mechanism]

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 19 Sep 2018 15:33:39 +0200

Noted for IPv6-over-OCB draft.

When the MAC address changes, the Interface ID (118bits) of the LL 
address MUST change too.

I will put that in the draft.

Alex

Le 14/09/2018 à 17:14, Christian Huitema a écrit :
> The stable IID algorithm is fine but if you want privacy you have to 
> ensure that the IID gets randomized whenever you randomize the MAC.
> 
> -- Christian Huitema
> 
> On Sep 14, 2018, at 7:01 AM, Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Hi,
>>
>> [email-masked] <mailto:[email-masked]>

---

From: Fernando Gont <[email-masked]>
Date: Wed, 19 Sep 2018 21:22:10 -0300

> But does this include the part of SLAAC that generates link-local addresses?

Configuration of LL addresses are said to be part of slaac. As such,
RFC8064 applies to LL addresses, too.

> dynamically changing a MAC address.

RFC8064 essentially points to implementation of RFC7217. And RFC7217
essentially says "take as many bits as needed from the hash function
(for the IID)". That is, RFC7217 is not bothered by the prefix length.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

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

> RFC8064 applies to LL addresses, too.

What is the prefix length SLAAC uses for link-local addresses?

(I am asking because I think it is undetermined, and because of that 
something that is part of something undetermined is also undetermined)

Alex

---

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

> On 09/14/2018 11:01 AM, Alexandre Petrescu wrote:
[...]
> (for the IID)". That is, RFC7217 is not bothered by the prefix length.

It is unimplementable.

Alex

---

From: Mark Smith <[email-masked]>
Date: Thu, 20 Sep 2018 18:02:50 +1000

> What is the prefix length SLAAC uses for link-local addresses?

RFC4291, 2.5.6.

---

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

Le 20/09/2018 à 10:02, Mark Smith a écrit :
> 
> 
> On Thu., 20 Sep. 2018, 15:50 Alexandre Petrescu, 

I think you did not understand my question.

RFC4291 'IPv6 Addr Arch' section 2.5.6 does _not_ specify the prefix 
length of a link-local address.

RFC4862 'SLAAC' does not specify it either.

This is why I think you did not understand my question.

Alex

---

From: Mark Smith <[email-masked]>
Date: Fri, 21 Sep 2018 08:35:36 +1000

> This is why I think you did not understand my question.

That is because section 2.6 specifies the format of IPv6 unicast addresses.

"prefix" is not the formal term for what you're asking about, although
it is common convention. "subnet prefix" is, and section 2.6 shows
that the subnet prefix length is 128 minus size of IID.

2.5.6 says LL IIDs are 64 bits, so the LL subnet prefix length is 64
bits. 2.5.6 is also specifying the values of all of those subnet
prefix bits, so the LL subnet prefix is fe80::/64.

Regards,
Mark.

---

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

> prefix bits, so the LL subnet prefix is fe80::/64.

That is what IANA should say: the LL subnet prefix is fe80::/64.

Alex

---

From: Mark Smith <[email-masked]>
Date: Fri, 21 Sep 2018 20:48:39 +1000

> That is what IANA should say: the LL subnet prefix is fe80::/64.

No, there's a difference.

fe80::/10 is the space that IANA have allocated for Link Local addresses.
IANA don't specify the format of the bits beyond /10.

RFC 4291 specifies when a Link Local address is formed on an interface, the
subnet prefix length of the LL address is /64, and the bits between
fe80::/10 and fe80::/64 are set to zero.

There could be a future LL address format or formats that fall within IANA
allocated fe80::/10 that don't have zero value bits for the remainer of the
subnet prefix.

For example, when an application uses LL addresses today, it has to also
specify the interface (zone index), as the LL prefix is non-unique.

Similar to how site-locals were in effect made unique by inserting a random
number, becoming Unique Local Addresses, Unique Link Local addresses could
be created by having a random number where the 54 zero bits exist today.
Once there are non-ambiguous Link Local subnet prefixes, applications would
not have to supply interface/zone information when using these unique Link
Local addresses.

Related to LLs, this work-in-progess ID might be useful to you, as I
collected together information about LLs in one place.

https://tools.ietf.org/html/draft-smith-ipv6-link-locals-apps-00

Regards,
Mark.

> >>>       >> addresses and other methods to achieve the same could be
> better,
> >>>      e.g.
> >>>      Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6
> >>>

---

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

Le 21/09/2018 à 12:48, Mark Smith a écrit :
> 
> 
> On Fri., 21 Sep. 2018, 14:43 Alexandre Petrescu, 
>      > <[email-masked]
>     <mailto:[email-masked]>> wrote:
>      >>
>      >>
>      >>
>      >>> <[email-masked]
>     <mailto:[email-masked]>
>     <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >>>
>      >>>
>      >>>
>      >>>       > On 09/14/2018 11:01 AM, Alexandre Petrescu wrote:
>      >>>       >> Hi,
>      >>>       >>
>      >>>       >> In RFC8064 'stable IIDs' are recommended to be used
>     for SLAAC.
>      >>>       >>
>      >>>       >> But does this include the part of SLAAC that generates
>      >>>      link-local addresses?
>      >>>       >
>      >>>       > Configuration of LL addresses are said to be part of
>     slaac. As such,
>      >>>       > RFC8064 applies to LL addresses, too.
>      >>>
> fe80::/10 is the space that IANA have allocated for Link Local 
> addresses. IANA don't specify the format of the bits beyond /10.

IANA calls it an 'IPv6 prefix' not a 'space' (see name of head of column 
1 of IANA URL "Internet Protocol Version 6 Address Space").

I think IANA does not know that IPv6 people talk 'prefix' to mean an 
'IPv6 subnet prefix': I advertise this prefix here, this other there.

That is different than talking 'prefix' like in prefix of phone numbers, 
or the n leading bits of a number read in a certain direction 
(left-to-write).

This is another reason why IANA should change it and not talk about 
'IPv6 prefix' when saying 'fe80::/10' but rather talk about the first 10 
bits of the string 'fe80::'.

RFC4291 is somehow explicit saying 'When it is used with the term 
"prefix" (e.g., "subnet prefix")...'

> RFC 4291 specifies when a Link Local address is formed on an interface, 
> the subnet prefix length of the LL address is /64,

Makes sense.

> and the bits between 

This no,  does not make sense.  The notation 'fe80::/10' denotes an IPv6 
subnet prefix, not the first 10 bits (leading bits).

> There could be a future LL address format or formats that fall within 
> IANA allocated fe80::/10 that don't have zero value bits for the 
> remainer of the subnet prefix.

These non-zero bits are part of the IPv6 subnet prefix or part of the 
leading bits denoting it to be a new link-local  address?

The confusion will only be continued.

> specify the interface (zone index), as the LL prefix is non-unique.

I am trying to make the link...

You mean that a new IANA space for link-local addresses could contain an 
interface index specified somewhere in the 54bits?

> Similar to how site-locals were in effect made unique by inserting a 
> random number, becoming Unique Local Addresses, Unique Link Local 
> addresses could be created by having a random number where the 54 zero 
> bits exist today. Once there are non-ambiguous Link Local subnet 
> prefixes, applications would not have to supply interface/zone 
> information when using these unique Link Local addresses.

To that, I can say that the ULA prefix is an even more complicated 
matter (fc vs fd).

> https://tools.ietf.org/html/draft-smith-ipv6-link-locals-apps-00

Thanks useful.  This is my immediate feedback to it:

It says both:
"The Link-Local unicast prefix is fe80::/10 [RFC4291]."
and
"the Link-Local prefix on a link is most commonly fe80::/64."

It's one or the other.

Yours,

Alex

>      >>>       >
>      >>>       >
>      >>>       >
>      >>>       >> I am asking because the part of SLAAC that generates
>     link-local
>      >>>       >> addresses is not clear on the prefix length.
>      >>>       >>
>      >>>       >> As such, I am tempted to believe RFC8064 does not apply to
>      >>>      link-local
>      >>>       >> addresses and other methods to achieve the same could
>     be better,
>      >>>      e.g.
>      >>>       >> dynamically changing a MAC address.
>      >>>       >
>      >>>       > RFC8064 essentially points to implementation of
>     RFC7217. And RFC7217
>      >>>       > essentially says "take as many bits as needed from the
>     hash function
>      >>>       > (for the IID)". That is, RFC7217 is not bothered by the
>     prefix
>      >>>      length.
>      >>>       >
>      >>>       > Thanks,
>      >>>       >
>      >>>
>      >>>     
>      >>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >>>      Administrative Requests:

---

From: Mark Smith <[email-masked]>
Date: Sat, 22 Sep 2018 11:41:59 +1000

> 1 of IANA URL "Internet Protocol Version 6 Address Space").

See the title of the document - "Internet Protocol Version 6 Address Space"

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

In the context of the "Internet Protocol Version 6 Address Space", the
fe80::/10 (10 bits with the hexidecimal value fe80) prefix identifies
the Link Local Address space.

In the context of RFC4921, when a Link Local address is configured on
an interface, the prefix is fe80::/64.

There are two different contexts here (Link Local Address space,
independent of a context where the address is applied and used; Link
Local Address generated and applied to an interface - a specific use
context), so there can be and are two different prefix lengths, even
though the upper 10 bits of both prefixes are the same.

> This no,  does not make sense.

That is what is specified in RFC4291 2.5.6 when forming a Link Local
address for an interface. If you don't put zero bits in that position,
you're not complying with RFC4291.

> The notation 'fe80::/10' denotes an IPv6

So what does the "/10" in "fe80::/10" mean if it doesn't mean "the
first 10 bits (leading bits)".

> leading bits denoting it to be a new link-local  address?

Depends on the prefix length. If the prefix length is /10, then the
"10" is saying the value of the remaining 118 bits are irrelevant for
where this /10 prefix is being referenced or used.

> The confusion will only be continued.

I don't agree. Different prefix lengths being applied to the same
portion of an address space is a well understood and implemented
concept. It goes back to at least RFC1519, "Classless Inter-Domain
Routing (CIDR): an Address Assignment and Aggregation Strategy".

> interface index specified somewhere in the 54bits?

No. Different hosts would have different interface indexes for the
their interfaces attached to the same link.

The idea is for a host to be able to use its route table to determine
the outgoing interface for a Link Local address, so that applications
don't have to care about interface indexes, similar to how it uses the
route table to determine outgoing interfaces for ULA or GUA addresses.
The route table can't be used today because the Link Local prefix on a
link is ambiguous, as the same prefix (fe80::/64) is duplicated across
all of a host's interfaces.

> "the Link-Local prefix on a link is most commonly fe80::/64."

You've missed the context in the second statement - "on a link".

Context always matters.

Regards,
Mark.

> >      >>>       >> addresses and other methods to achieve the same could
> >     be better,
> >      >>>      e.g.
> >      >>>       > (for the IID)". That is, RFC7217 is not bothered by the
> >     prefix
> >      >>>      length.
> >      >>>       >
> >      >>>       > Thanks,
> >      >>>       >
> >      >>>
> >      >>>

---

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

[...]
> 2.5.6 says LL IIDs are 64 bits,

It does not really write it.

It illustrates it.

An illustration can be read in many different ways.

Alex

> so the LL subnet prefix length is 64

---

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

Le 22/09/2018 à 03:41, Mark Smith a écrit :
[...]
> an interface, the prefix is fe80::/64.

On a computer it is "fe80::/64" and on RFC it is "fe80::/10"?

But there are computers on which it can also be "fe80::/10".

(on linux type "ifconfig eth0 add fe80::/1").

> first 10 bits (leading bits)".

Right.

WE turn in rounds.

> Routing (CIDR): an Address Assignment and Aggregation Strategy".

Er?  CIDR does not apply to 'connected' routes, i.e. the routes in the 
routing table but without a next hop.  Those were LL addresses are valid.

> all of a host's interfaces.

The idea makes sense.  But I dont understand where to get that magic 
parameter from (if not from iface name).

> You've missed the context in the second statement - "on a link".

Now I got it.

It is what Jinmei Tatuya calls "subnet prefix".

Both of you people are saying that the LL space is "fe80::/10" yet the 
"on a link prefix" aka "subnet prefix" is "fe80::/64".

I will put that like that in the draft.

> Context always matters.

... in a section called "Context".

Alex

---

From: Mark Smith <[email-masked]>
Date: Mon, 24 Sep 2018 21:19:52 +1000

> An illustration can be read in many different ways.

I don't find the following ambiguous. The subnet prefix length is 128
bits minus the IID size (RFC4291, 2.5), so the subnet prefix length of
a Link Local address when configured on an interface is 128 - 64 or a
64 bit subnet prefix. Therefore, the Link Local subnet prefix portion
of the address, when configured on an interface, is fe80::/64.

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

Regards,
Mark.