Subject: RE: 64bit MAC addresses and SLAAC

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 17 Jun 2020 17:44:39 +0000

Hi Ole,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, June 17, 2020 9:36 AM
> To: Templin (US), Fred L <[email-masked]>
> Cc: 6man WG <[email-masked]>
> Subject: Re: 64bit MAC addresses and SLAAC
> Fred,
> 
> > Fernando, I think an unspoken assumption in these past several messages is that
> > privacy is ALWAYS a required property. However, there are cases where address
> > privacy is not only not required, but it is also desirable and useful to be able to
> > track a node by a stable and unchanging IP address or prefix.
> >
> > This is not intended to challenge the non-use of MAC addresses in Interface
> > Identifiers per your documents, but just to say that in some environments the
> > randomization and constant changing of IP addresses may actual run counter to
> > operational objectives.
> 
> Implementations and operational deployments or other link-types are of course free to choose whatever recommendation (or none)
> for default IID generation.
> IID mechanisms are not protocol specifications. They are recommendations taking various parameters into account (stability, tracking
> etc).
> These are not required for interoperability.
> Configure IIDs manually if you like.

You seem to be acknowledging my point that privacy is not always a required property,
and that in some environments stability, tracking, etc. are desirable. And, for those types
of environments, placing a constant-value token somewhere in the address (whether it
came from a hardware code, administrative setting or algorithmic generation) should be
fine. Did I understand correctly?

Thanks - Fred

> Cheers,
> Ole=

---

From: [email-masked]
Date: Wed, 17 Jun 2020 19:52:22 +0200

Fred,

> fine. Did I understand correctly?

Yes, largely.
Strictly speaking, standardizing mechanisms for generating IIDs is in the grey area of over-specifying.
Look at it as general recommendations, if you don't know better.
And we have always supported manual configuration of course.

Best regards,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Wed, 17 Jun 2020 15:43:28 -0300

> Strictly speaking, standardizing mechanisms for generating IIDs is in the grey area of over-specifying.

In a way, *the RFCs updated by RFC8064* were the ones specifying IID 
generation algorithms. In a way, RFC8064 relaxes such specs, and 
replacing a hard-coded algorithm (embedding MAC addresses) with actual 
requirements for the IIDs, and recommends an algorithm (RFC7217), so 
that you don't need to figure out how to comply to the aforementioned 
requirements by yourself.

-- 
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, 18 Jun 2020 16:10:11 +0200

Le 17/06/2020 à 19:52, [email-masked] a écrit :
> Fred,
> 
>>>> Fernando, I think an unspoken assumption in these past several
>>>> messages is that privacy is ALWAYS a required property.
>>>> However, there are cases where address privacy is not only not
>>>> required, but it is also desirable and useful to be able to 
>>>> This is not intended to challenge the non-use of MAC addresses
>>>> in Interface Identifiers per your documents, but just to say
>>>> that in some environments the randomization and constant
>>>> changing of IP addresses may actual run counter to operational
>>>> objectives.
>>> 
>>> Implementations and operational deployments or other link-types
>>> are of course free to choose whatever recommendation (or none) 
>>> for default IID generation. IID mechanisms are not protocol
>>> specifications. They are recommendations taking various
>>> parameters into account (stability, tracking etc). These are not
>>> required for interoperability. Configure IIDs manually if you
>>> like.
>> 
>> You seem to be acknowledging my point that privacy is not always a
>> required property, and that in some environments stability,
>> tracking, etc. are desirable. And, for those types of environments,
>> placing a constant-value token somewhere in the address (whether
>> it came from a hardware code, administrative setting or algorithmic
>> generation) should be fine. Did I understand correctly?
> 
> Yes, largely. Strictly speaking, standardizing mechanisms for
> generating IIDs is in the grey area of over-specifying.

YEs, gray area, but probably not over-specifying.

For comparison, ULA specs do suggest three alternative methods for
generating the subnet ID part of the address.

> Look at it as general recommendations, if you don't know better. And
> we have always supported manual configuration of course.

True.

I want to tell why I did not feel overwhelmed by over-specification, but
rather I feared hardcoding, and fear of reducing flexibility.

We looked for the place in linux which forces the 64bit limit in SLAAC.
  We found it and we wondered what to put in these - potentially 66 -
bits of an IID?   The immediate thought was to put there random numbers.
  These random numbers seemed natural to several of us.  And they offer
privacy.

But is it the right thing to do?

If we do that (put random numbers in a variable length IID) that's what
gets fixed there again for years.

If we put random numbers in there then for years again the users will
find it difficult to remember those scrambled numbers when typing ifconfig.

If we put random numbers in there then for years again people will look
for easy to use, license-free, platform-independent, high performance,
speedy, C standard, less energy consuming, almost-true random,
primitives to call; and their seeds.

This is how I came to that idea that maybe a MAC address could also be a
potential source of data to put in the IID: take 64bits of a MAC address
and stick two zeros into it to make a 66bit IID.  Or some other variant,
depending on the need of the length of the IID.

Somnething that is quick to implement.

Alex

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

---

From: Philip Homburg <[email-masked]>
Date: Thu, 18 Jun 2020 17:31:16 +0200

> We looked for the place in linux which forces the 64bit limit in

Which make sense, because that is what the RFC says.

>   We found it and we wondered what to put in these - potentially
>   66 - bits of an IID?   The immediate thought was to put there
> random numbers.
>   These random numbers seemed natural to several of us.  And they
>   offer privacy.

I'm sure that if SLAAC is updated to allow other lengths, some consideration
will be given to generating IIDs. However, at the moment SLAAC is 64-bit
even if some implementations try to be more flexible.

> If we put random numbers in there then for years again the users
> will find it difficult to remember those scrambled numbers when
> typing ifconfig.

That is the nature of SLAAC. You need an IID that has a very high probabily
of being unique. So you need enough random bits.

If you want easy to remember addresses, go for DHCPv6.

> If we put random numbers in there then for years again people will
> look for easy to use, license-free, platform-independent, high
> performance, speedy, C standard, less energy consuming, almost-true
> random, primitives to call; and their seeds.

It is not to hard to find an SHA2-HMAC implementation.

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 19 Jun 2020 10:39:00 +0200

Le 18/06/2020 à 17:31, Philip Homburg a écrit :
>> bits of an IID?   The immediate thought was to put there random
>> numbers. These random numbers seemed natural to several of us.  And
>> they offer privacy.
> 
> I'm sure that if SLAAC is updated to allow other lengths, some
> consideration will be given to generating IIDs. However, at the
> moment SLAAC is 64-bit even if some implementations try to be more
> flexible.
> 
> That is the nature of SLAAC. You need an IID that has a very high
> probabily of being unique. So you need enough random bits.

Indeed it seems so that nature.  If one wants numbers that are likely to
be unique, probably random numbers are the easiest and safest choice.

Maybe a 14 volume Oxford dictionary indexed by a random pointer would
still issue words likely to be unique.

Probably that kind of generation is more particular to DHCPv6, or so.

Alex

>> performance, speedy, C standard, less energy consuming,
>> almost-true random, primitives to call; and their seeds.
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 19 Jun 2020 09:09:15 +0000

Hello Phil

> 
> That is the nature of SLAAC. You need an IID that has a very high probabily of
> being unique. So you need enough random bits.
> 
Is this really, deep down, the nature of SLAAC? Or the consequence of not having a very fast and reliable DAD?
Arguably one could autoconfig even IPv4 within a /24 if there's a broker that serializes the requests and rejects the duplicates. 
The large IPv6 address space allowed DAD to be lousy, simple to operate in a distributed fashion, and still appear to work.
But because we know it does not, we rely on chance and large numbers vs. tackling the engineering problem.

Keep safe,

Pascal

---

From: Philip Homburg <[email-masked]>
Date: Fri, 19 Jun 2020 15:34:45 +0200

>  of
> Is this really, deep down, the nature of SLAAC? Or the consequence
> of not having a very fast and reliable DAD? Arguably one could
> autoconfig even IPv4 within a /24 if there's a broker that serializes
> the requests and rejects the duplicates.  

We have that broker, it is called DHCPv6.

Absent such a centralized service, a host would have a hard time proving that
a address unique, for example, there might be a network split.

Current DAD is certainly not good enough if there are regular address
collisions and I doubt anybody is willing to come up with a better DAD
just to have nicer looking addresses in SLAAC.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 19 Jun 2020 13:54:22 +0000

> > >
> > Is this really, deep down, the nature of SLAAC? Or the consequence of
> > not having a very fast and reliable DAD? Arguably one could autoconfig
> > even IPv4 within a /24 if there's a broker that serializes the
> > requests and rejects the duplicates.
> 

As of today? Depending on what you expect from that broker, e.g., who gets to select the IID, can you use the broker for Address Resolution, etc... 
DHCP is a swiss knife. With a few more blades it would fit the bill nicely. ND could too. There are other candidates but I'd rather upgrade those two to start with.

> 
> Absent such a centralized service, a host would have a hard time proving that a
> address unique, for example, there might be a network split.

We agree

> Current DAD is certainly not good enough if there are regular address collisions

Define "regular". I will agree if it is the opposite of quasi-impossible, which is how we get SLAAC to work.
Thus your original shortcut that SLAAC=>randomIID though deep down it does not, it's just how we do it with distributed DAD.

> and I doubt anybody is willing to come up with a better DAD just to have nicer
> looking addresses in SLAAC.

It's not just DAD, it's the whole ND system that has aged and needs a lifting. Think wireless, overlays, NBMA meshes, large L2 domains...

Keep safe;

Pascal

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 19 Jun 2020 14:16:26 +0000

Hi Pascal,

> It's not just DAD, it's the whole ND system that has aged and needs a lifting.

I don't think there is any need for changes to ND [RFC4861].

> Think wireless, overlays, NBMA meshes, large L2 domains...

We have all of these aspects covered under the AERO/OMNI approach using ND
per RFC4861 and with a new NBMA interface type.

Thanks - Fred

> From: ipv6 [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
> Sent: Friday, June 19, 2020 6:54 AM
> To: Philip Homburg <[email-masked]>; [email-masked]
> Subject: RE: 64bit MAC addresses and SLAAC
> 
> > > >
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Philip Homburg <[email-masked]>
Date: Fri, 19 Jun 2020 16:28:19 +0200

> As of today? 

I don't think the protocol has any limitations in this regard. I.e,
a host could wait for an RA with a PIO option, generate an address and then
use DHCPv6 to obtain that address.

Whether any host does that or any dhcp server supports it is a different 
question. It doesn't need protocol changes.

> Depending on what you expect from that broker, e.g.,
> who gets to select the IID, 

The host can propose an IID, the DHCPv6 server is the final authority.

> can you use the broker for Address
> Resolution, etc...  

Obviously, DHCPv6 is not going to do address resolution.

> Define "regular". I will agree if it is the opposite of quasi-impossible,
> which is how we get SLAAC to work.  Thus your original shortcut
> that SLAAC=>randomIID though deep down it does not, it's just how
> we do it with distributed DAD.

Current SLAAC has to work with current DAD. Only after we change DAD, we can
consider changing SLAAC. 

Having two hosts with the same IP address on a subnet is very hard to 
troubleshoot. So we have to keep the chance of that happening very low.

Using 64-bit pseudo random numbers is a very effective way of doing that.

> It's not just DAD, it's the whole ND system that has aged and needs
> a lifting. Think wireless, overlays, NBMA meshes, large L2 domains...

Address resolution using multicast can trivially be disabled
(except for link local) by marking prefixes as offlink.

I think that offers plenty of flexibility.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 19 Jun 2020 16:49:35 +0000

> Address resolution using multicast can trivially be disabled (except for link
> local) by marking prefixes as offlink.

Ain't you missing anything?

The good news is that most of the ND heavy lifting that was needed is already done.

- the router still needs the resolution. There's stuff in draft-ietf-6man-grand and/or RFC 8505 for that.
- handling mobility vs. anycast. There's stuff in draft-ietf-rift-rift-12#section-4.3.3.3 for that.
- all NBMAs are not hub and spoke so there's a routing game to trigger. There's stuff in draft-ietf-roll-unaware-leaves for that.
- still need to feed the mapping server for the overlay. There's stuff in draft-thubert-6man-unicast-lookup for that.
- zerotrust / SAVI is also missing and SEND did not cut it. There's stuff in draft-ietf-6lo-ap-nd for that.

For more detaiuls, there's draft-thubert-6man-ipv6-over-wireless, just let you go over it and comment if you really care.

In the meantime I'll go ahead and try to understand what the aero/omni really brings to the party.

Keep safe;

Pascal

---

From: Philip Homburg <[email-masked]>
Date: Mon, 22 Jun 2020 11:15:25 +0200

> - the router still needs the resolution. There's stuff in
> draft-ietf-6man-grand and/or RFC 8505 for that.  - handling mobility
> vs. anycast. There's stuff in draft-ietf-rift-rift-12#section-4.3.3.3
> for that.  - all NBMAs are not hub and spoke so there's a routing
> game to trigger. There's stuff in draft-ietf-roll-unaware-leaves
> for that.  - still need to feed the mapping server for the overlay.
> There's stuff in draft-thubert-6man-unicast-lookup for that.  -
> zerotrust / SAVI is also missing and SEND did not cut it. There's
> stuff in draft-ietf-6lo-ap-nd for that.
> 
> For more detaiuls, there's draft-thubert-6man-ipv6-over-wireless,
> just let you go over it and comment if you really care.

Link address resolution can be solved to colocating a DHPCv6 relay with the
router. The relay can maintain IPv6 address to link layer address mappings
and inject those into the router's neighbor cache.

It seems to me that letting a host generate an address using SLAAC and then
forcing the host to register the address somewhere is just all of the work that
DHCPv6 does with none of the benefits.

Of course, if DHCPv6 would be allowed to have a default router option, then the
use of multicast could be reduced even further.

---

From: [email-masked]
Date: Mon, 22 Jun 2020 12:14:09 +0200

Philip,

> DHCPv6 does with none of the benefits.

Indeed.

> use of multicast could be reduced even further.

If there is interest I suppose I could ask for adoption of:
https://datatracker.ietf.org/doc/draft-troan-6man-universal-ra-option/

Cheers,
Ole

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 22 Jun 2020 12:45:33 +0000

>> DHCPv6 does with none of the benefits.

Indeed not, 

though it could be done that way as well... basically the dhcp server provisioning the ND cache of the routers in the back end as opposed to any of the routers telling the server - which is how we did it.

Bottom line is that it’s a game of one host multiple routers and one server. If DHCP is your hammer feel free to use it. Intuitively it’s simpler to me For the host to tell the router and then the router does what’s needed, e.g. ask dhcp if present, inject in evpn if present etc.. going through dhcp to do that job imposes dhcp everywhere,  or my inclination. 

Note that dhcp does not save DAD in the first place so the loop is complete.

:)

Pascal