Re: 64bit MAC addresses and SLAAC

>
> But there are certainly computing&communicating platforms not powerful
> enough to run AES.

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

That "probably" is the saving grace :)

I'd go for IPv6 on any communicating device and give in to alternatives
with very great reluctance.

On Fri, Jun 19, 2020 at 12:04 AM Mark Smith <markzzzsmith@gmail.com> wrote:

>
>
> On Fri, 19 Jun 2020, 00:30 Alexandre Petrescu, <
> alexandre.petrescu@gmail.com> 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
>> >     <pch-ipv6-ietf-6@u-1.phicoh.com
>> >     <mailto:pch-ipv6-ietf-6@u-1.phicoh.com>> 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
>> >         ipv6@ietf.org <mailto:ipv6@ietf.org>
>> >         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
>> >     ipv6@ietf.org <mailto:ipv6@ietf.org <ipv6@ietf..org>>
>> >     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> >     --------------------------------------------------------------------
>> >
>> >
>> > --------------------------------------------------------------------
>> > IETF IPv6 working group mailing list
>> > ipv6@ietf.org
>> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> > --------------------------------------------------------------------
>> >
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> 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