Re: 64bit MAC addresses and SLAAC

[Etienne-Victor Depasquale <[e-mail]>]

>
> Right tool for the job


Agreed.

And here's another point.

Is it fair to say that the drive to converge on IP in so many aspects of
telecommunication makes it the first choice?
Definitely.

On Fri, Jun 19, 2020 at 12:20 PM Mark Smith <[e-mail]> wrote:

>
>
> On Fri, 19 Jun 2020, 19:18 Etienne-Victor Depasquale, <[e-mail]>
> wrote:
>
>> 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.
>>
>
>
> "Right tool for the job", as my father taught me.
>
> I'm also reminded of how good a blade screwdriver is at opening a paint
> can, except that doing that ruins the blade screwdriver for undoing screws!
> Buy a cheap blade screwdriver and call it a "paint can opener", making it
> then the right tool for the job, and also accepting that it can't be
> reliably used as a screwdriver anymore.
>
>
>
>
>
>>
>>
>> On Fri, Jun 19, 2020 at 12:04 AM Mark Smith <[e-mail]>
>> wrote:
>>
>>>
>>>
>>> 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] <ipv6@ietf..org>>
>>>> >     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
>>>> --------------------------------------------------------------------
>>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> [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
>>
>

-- 
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