RE: [EXTERNAL] Re: 64bit MAC addresses and SLAAC

["Pascal Thubert (pthubert)" <[e-mail]>]

Spot on, Fred.

There are cases where anonymity is entirely undesirable. 

E.g., machines do not have complexes but may be complex to locate and manage. Whether we at 6MAN like it or not, some standards out there tie the role of a device to its IPv6 address, so you can replace the device with a spare, give it the same IPv6 address / keys and keep using it/managing it as you did. Look at ISA100.11a for an example. Note on the side that Internet connectivity is the least of the concerns of a control network. In fact the risk of being connected unknowingly to the Internet is a deterrent for IPv6 adoption (vs. mission - specific and proprietary protocols). 

Also +1 to Kerry. Some standards (including ours) can do a preferred treatment if the IPv6 address derives from the MAC. Note that this looks antinomic with the spare part goal above; that would indeed be antinomic for burn-in MAC addresses; but there are also standards out there that use a shorter assigned MAC address, e.g., to reduce the frame size and save energy and bandwidth; in that case you can have both properties of deriving the IPv6 address from the MAC and replacing a failing device by a virtually identical one.

I support documenting pro/cons of address allocation behaviors, but I object constraining how people use IPv6, be it flow label, address format, routing headers and all, because of one's use case or religion. There are others.

Keep safe;

Pascal
> -----Original Message-----
> From: ipv6 <[e-mail]> On Behalf Of Templin (US), Fred L
> Sent: mercredi 17 juin 2020 18:18
> To: Fernando Gont <[e-mail]>; Alexandre Petrescu
> <[e-mail]>; Bob Hinden <[e-mail]>
> Cc: IPv6 List <[e-mail]>
> Subject: RE: [EXTERNAL] Re: 64bit MAC addresses and SLAAC
> 
> 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.
> 
> Thanks - Fred
> 
> > -----Original Message-----
> > From: ipv6 [mailto:[e-mail]] On Behalf Of Fernando Gont
> > Sent: Wednesday, June 17, 2020 8:21 AM
> > To: Alexandre Petrescu <[e-mail]>; Bob Hinden
> > <[e-mail]>
> > Cc: IPv6 List <[e-mail]>
> > Subject: [EXTERNAL] Re: 64bit MAC addresses and SLAAC
> >
> > This message was sent from outside of Boeing. Please do not click
> > links or open attachments unless you recognize the sender and know that the
> content is safe.
> > On 17/6/20 08:39, Alexandre Petrescu wrote:
> > > Le 15/06/2020 à 23:01, Bob Hinden a écrit :
> > >> Alexandre,
> > >>
> > >>> On Jun 15, 2020, at 1:23 PM, Alexandre Petrescu
> > >>> <[e-mail]> wrote:
> > >>>
> > >>> Hi,
> > >>>
> > >>> Before the sanitary situation I was studying an issue at ISO.
> > >>>
> > >>> The issue is about 64bit MAC addresses and SLAAC.
> > >>>
> > >>> SLAAC needs a 48bit MAC addresses in order to work, and it can not
> > >>> work with a 64bit MAC address; (but yes, it can with 64bit IIDs).
> > >>
> > >> SLACC does not specify the length of the Interface ID, it does not
> > >> require require 48-bit MAC addresses, and the reason for Modified
> > >> EUI-64 Format Interface Identifiers in RFC4291 was to support 64bit
> > >> EUI-64 Identifiers.   We have since moved away from using MAC
> > >> addresses as Interface IDs.  See RFC 8064.
> > >
> > > Bob,
> > >
> > > RFC8064 says "this document [...] recommends against embedding
> > > stable link-layer addresses in IPv6 Interface Identifiers".
> > >
> > > But a 64bit MAC address could be a random number as well, not
> > > necessarily stable.  Windows randomizes some of its MAC addresses.
> >
> > Reusing IDs in multiple contexts is known to be a bad idea. See e.g.:
> > https://tools.ietf.org/html/draft-irtf-pearg-numeric-ids-generation
> > and
> > https://tools.ietf.org/html/draft-gont-numeric-ids-sec-considerations
> >
> > Thanks,
> > --
> > Fernando Gont
> > SI6 Networks
> > e-mail: [e-mail]
> > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> >
> >
> >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------