Re: 64bit MAC addresses and SLAAC

[Mark Smith <[e-mail]>]

On Fri, 19 Jun 2020, 00:30 Alexandre Petrescu, <[e-mail]>
wrote:

>
>
> Le 18/06/2020 à 09:50, Mark Smith a écrit :
> >
> >
> <snip>
> >
> >
> > So I have a couple of IoT IPv6 books from about 10 years ago, and they
> > talk about these battery powered devices having AES implementations to
> > encrypt the radio layer.
> >
> > So it seems AES was cheap enough to do in battery powered IoT devices 10
> > years ago, so I would assume it is even cheaper to do now.
> >
> > I understand crypto algorithms can also be used as a hash generator, so
> > perhaps the AES in these things can be used to generate hashes for
> > RFC7217 stable IDs.
>
> Probably AES is not an issue on some platforms, in terms of having
> enough cycles.
>
> But there are certainly computing&communicating platforms not powerful
> enough to run AES.
>

So IPv6 is probably not the right protocol for those devices.

It's great to try to use IPv6 for everything, but it doesn't mean IPv6 must
be used for everything.

IPv6 is a general purpose internetworking protocol, so it isn't going to be
optimal for all cases.

At some point, the compromises or costs of using IPv6 will outweigh the
benefits of using a general commodity protocol. At that point, the expense
of a better suited and more specific protocol to suit the problem protocol
is worth paying.

The IoT applications being discussed are local network only applications.
Since an internetworking protocol solves a much bigger problem -
internetworking hosts attached to a network of networks, using an
internetworking protocol to solve a local network application problem is
always going to involve a compromise - accepting a larger packet overhead
because of using an address space that is far larger than it needs to be to
solve the problem.

Unfortunately we don't really have a middle ground, general purpose, yet
local network only protocol. MPLS is close, but not really general purpose
enough.

Now that IPv4 can't solve the Internet internetworking problem (hence
invention of IPv6), perhaps we should repurpose it to use for local network
only application problems.

Regards,
Mark.



> And, it is not only a matter of energy consumption or time it takes to
> compute.
>
> There are very many additional aspects involved in using crypto
> technology, at all layers from 0 to Political.  Bind them all to an IP
> address?
>
> Alex
>
> >
> > Regards,
> > Mark.
> >
> >
> >
> >     Alternatively:
> >     keep link-layer addresses in IPv6 IIDs,
> >     without allowing unauthorized data collection from the nodes,
> >     by implementing access control to the nodes at the (mains-powered)
> >     border router.
> >
> >     Etienne
> >
> >     On Wed, Jun 17, 2020 at 11:54 PM Philip Homburg
> >     <[e-mail]
> >     <mailto:[e-mail]>> wrote:
> >
> >          >   Of course the caveat there with unmanaged network and SOHO
> >         and Mobile
> >          >where manual or DHCPV6 is not possible or viable.
> >
> >         Why is DHCPv6 not possible? Of course there is the Android
> problem.
> >         But I doubt that a low power IoT device would share a wifi-link
> >         with an
> >         Android device.
> >
> >          >    In those cases SLAAC is preferred, but then we have the
> >         crux of
> >          >    issue and the decision tree on privacy random IID and its
> >         overhead
> >          >    if its not necessary versus modified EUI64.
> >          >    tree of course the underlying operational impacts of random
> >          >    versus  stable IID double edged sword operator or
> individuals
> >          >    decision to pick which works best for their use case.  In
> the
> >          >    end net-net is what is simplest to deploy and least
> overhead
> >          >    but also meets the desired goal is generally the thought
> for
> >          >    picking the IID generation solution. For that SLAAC wins
> >         out in
> >          >    that decision for the use case described above.
> >
> >         A stable, unique pseudo random IID per prefix basically requires
> one
> >         SHA2-HMAC (or equivalent in SHA3 or other modern hash function)
> per
> >         prefix.
> >
> >         I cannot imagine that computing 2 SHA2 hashes has a significant
> >         amount
> >         of energy use compared to link attachment and duplicate address
> >         detection.
> >
> >         This computation is once per prefix, so it becomes an issue if
> the
> >         devices frequently attaches to new links. In which case tracking
> >         protection
> >         becomes important.
> >
> >         I also wonder, a device that cannot afford a couple SHa2 hashes?
> >         Then that
> >         device is probably insecure and should not be connect to the
> >         internet
> >         anyhow.
> >
> >
> >
>  --------------------------------------------------------------------
> >         IETF IPv6 working group mailing list
> >         [e-mail] <mailto:[e-mail]>
> >         Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6
> >
>  --------------------------------------------------------------------
> >
> >
> >
> >     --
> >     Ing. Etienne-Victor Depasquale
> >     Assistant Lecturer
> >     Department of Communications & Computer Engineering
> >     Faculty of Information & Communication Technology
> >     University of Malta
> >     Web. https://www.um.edu.mt/profile/etiennedepasquale
> >     --------------------------------------------------------------------
> >     IETF IPv6 working group mailing list
> >     [e-mail] <mailto:[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
> > --------------------------------------------------------------------
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>