Subject: 64bit MAC addresses and SLAAC

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 15 Jun 2020 22:23:35 +0200

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

The document ISO/CD 22738:2019(E) under development at that time does 
specify a 64bit MAC address for optical camera communications (OCC, akin 
to IEEE 802.15.7).

This might be an additional requirement for SLAAC improvements.  Or not.

Alex

---

From: Bob Hinden <[email-masked]>
Date: Mon, 15 Jun 2020 14:01:59 -0700

Alexandre,

> On Jun 15, 2020, at 1:23 PM, Alexandre Petrescu <[email-masked]> wrote:
> 
> Hi,
> 
> 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

> 
> The document ISO/CD 22738:2019(E) under development at that time does specify a 64bit MAC address for optical camera communications (OCC, akin to IEEE 802.15.7).
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 16 Jun 2020 10:38:04 -0500

On Mon, Jun 15, 2020 at 4:02 PM Bob Hinden <[email-masked]> wrote:

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

+1

Behcet

> specify a 64bit MAC address for optical camera communications (OCC, akin to
> IEEE 802.15.7).
> >

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 17 Jun 2020 13:16:41 +0200

Le 16/06/2020 à 17:38, Behcet Sarikaya a écrit :
> 
> 
> On Mon, Jun 15, 2020 at 4:02 PM Bob Hinden <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> Alexandre,
> 
>> On Jun 15, 2020, at 1:23 PM, Alexandre Petrescu
> <[email-masked] <mailto:[email-masked]>>
>  wrote:
>> 
>> Hi,
>> 
>> 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.
> 
> 
> 
> +1

Well, I tend to agree with some aspects, but disagree with others.

I agree that putting a MAC address in clear in an IP address raises
significant privacy issues.  These issues should be dealt with, and have
been so.

One way is to use RFC7217 and RFC8064 which, when implemented, offer a
means to put a random number in these many bits of an IID of an IP
address, rather than a hard-wired and thus easily trackable MAC address.

However, that view is not necessarily enough.

There are many problems with RFC7217 plus RFC8064, among which:

- RFC8064 recommends simply stable IIDs; to do that it uses RFC7217
   which defines stables IIDs _within_ a subnet.  That is an
   inconsistency.  A stable IID with a stable prefix is often needed for
   mobility, and, a same IID within distinct prefixes might ease
   administration; yet none of these two aspects seems mentioned.

- neither RFC8064 nor RFC7217 mention the use of random numbers in MAC
   addresses.  Yet that is implemented in Windows at least.

- RFC8064 is somehow not implemented in linux, even though linux does
   offer privacy IIDs.  The part of RFC8064 that is not implemented in
   linux is the part that says that the IID length can be anything and
   not necessarily 64.

Because of these reasons, generally speaking about SLAAC and IID
generation, there might still be other necessary ways to generate IIDs
than just 64bit random IIDs.  Easy to remember IIDs, same IIDs for
distinct interfaces, are a couple of new potential rules that come to mind.

If so, probably the easiness of generating IP addresses containing MAC
addresses might also be a good idea in some context: just copy paste the
64bit (random) MAC address to the last 8 bytes of the IP address.

Alex

> Behcet
> 
> Bob
> 
> 
>> 
>> The document ISO/CD 22738:2019(E) under development at that time
> does specify a 64bit MAC address for optical camera communications 
> (OCC, akin to IEEE 802.15.7).
>> 
>> [email-masked] <mailto:[email-masked]> Administrative Requests: 
>> https://www.ietf.org/mailman/listinfo/ipv6 
>  IETF IPv6 working group mailing list [email-masked] 
> <mailto:[email-masked]> Administrative Requests: 
> https://www.ietf.org/mailman/listinfo/ipv6

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 17 Jun 2020 13:39:09 +0200

Le 15/06/2020 à 23:01, Bob Hinden a écrit :
>> <[email-masked]> wrote:
>> 
>> Hi,
>> 
>> 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).
> 

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.

That aside, I am not sure how much RFC8064 is clear about the length of
an IID (it refers to RFC7217 '_could_ any len'), neither am I sure how
much is it implemented (linux and freebsd implement random IIDs but of
fixed length).

Alex

---

From: Fernando Gont <[email-masked]>
Date: Wed, 17 Jun 2020 12:00:50 -0300

On 15/6/20 17:23, Alexandre Petrescu wrote:
> SLAAC needs a 48bit MAC addresses in order to work,

Nope. SLAAC nees you to come up with a 64-bit IID. It used to be the 
case that link-layer-specific RFCs would tell you how to come up with 
such a 64-bit IID -- typically based on the underlying MAC address. -- 
but we have moved away with that (see RFC8064 and RFC7217)

> and it can not work 

Quite the contrary, the SLAAC IID length was changed from 48-bits to 
64-bits to accommodate link-layers that employ 64-bit link-layer addresses.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Wed, 17 Jun 2020 12:13:26 -0300

On 17/6/20 08:16, Alexandre Petrescu wrote:
[....]
>    administration; yet none of these two aspects seems mentioned.

RFC8064 describes desired properties for stable addresses. RFC7217 
specifies an algorithm that allows the generation of addresses with such 
properties.

TL;DR : RFC7217 aims at producing IIDs that are stable within the same 
network, but that change as the node moves to other networks.

The case of "same IID with distinct prefixes" is the same as using the 
same IID as the host moves from one network to another. And that's quite 
bad for privacy. PLease see RFC7721.

>    addresses.  Yet that is implemented in Windows at least.

It doesn't, and it shouldn't. If you randomize MAC addresses, you may 
want to use temporary-only. rfc4941bis allows you to do that.

>    offer privacy IIDs.

Quite the contrary: Linux was the first implementation of RFC7217. 
RFC7217 is currently implemented in virtually all (*) host operating 
systems, including Mac OS, OpenBSD, and virtually all LInux distributions.

There's a Linux kernel implementation, plus an implementation in 
systemd-networkd, NetworkManager, and dhcpcd.

>  The part of RFC8064 that is not implemented in

You are misreading RFC7217. RFC7217 simply says that the algorithm is 
not tied to any specific prefix length -- which, if one looks at the 
algorithm, should be evident. That said, the addressing architecture 
calls for 64-bit IIDs.

> 64bit (random) MAC address to the last 8 bytes of the IP address.

RFC8064 says you shouldn't. But, as "SHOULD/SHOULD NOTs" go, you may 
behave otherwise if you feel you know better.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 17 Jun 2020 12:20:38 -0300

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

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 17 Jun 2020 15:46:24 +0000

Hi Experts,
The life is even more complicated than Alexandre just mentioned.
Yea, it make sense to check RFC 8064 and RFC 7217 ("semantically opaque") carefully that nothing contradicts to 64 bits MAC.
Microsoft is effectively using RFC 4941, but without regeneration of address over time. I am not sure that it make sense to look into RFC 4941, it is not exactly Microsoft anyway.
But may be it make sense to look into "draft-fgont-6man-rfc4941bis" - refresh for "random".

The problem that it is not the end of the challenge.

I am not sure how much is relevant old (not popular) RFC 3972 (“cryptographically generated addresses”). It is active formally, just almost nobody use it.

Mobile guys have decided to greatly simplify SLAAC for P2P GTP tunnel. Interface ID is proposed by Mobile Core (TE should accept) - see RFC 7849.

Moreover, because many parameters are not possible to deliver by SLAAC (SIP gateway, TR-069 server, Prefix Delegation for LAN behind CPE/UE/RG, ...) and Carriers need to track IP for LI anyway -
Many carriers have chosen to use stateful DHCP in Telco environment. Hence, the latest DHCPv6 (RFC 8415) could be the subject of investigation too.

And finally: It was a mess for "what to use as DHCP IDs (DUID)". RFC 7513 is trying to sort it out. MAC is again touched here very much.

Bob,
May be you have some restrictions on use cases - then you do not need to investigate all of these.
I have no clue how much 64bit MAC would contradict (and need to refresh respective RFC) in all cases above - I did not try to read it with this problem in mind.
But may be it would be useful for you to have the full list.

Eduard
-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: 17 июня 2020 г. 14:17
To: [email-masked]; Bob Hinden <[email-masked]>
Cc: IPv6 List <[email-masked]>
Subject: Re: 64bit MAC addresses and SLAAC

Le 16/06/2020 à 17:38, Behcet Sarikaya a écrit :
> not work with a 64bit MAC address; (but yes, it can with 64bit IIDs).
> 

I agree that putting a MAC address in clear in an IP address raises significant privacy issues.  These issues should be dealt with, and have been so.

One way is to use RFC7217 and RFC8064 which, when implemented, offer a means to put a random number in these many bits of an IID of an IP address, rather than a hard-wired and thus easily trackable MAC address.

Because of these reasons, generally speaking about SLAAC and IID generation, there might still be other necessary ways to generate IIDs than just 64bit random IIDs.  Easy to remember IIDs, same IIDs for distinct interfaces, are a couple of new potential rules that come to mind.

If so, probably the easiness of generating IP addresses containing MAC addresses might also be a good idea in some context: just copy paste the 64bit (random) MAC address to the last 8 bytes of the IP address.

Alex

---

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

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

> From: ipv6 [mailto:[email-masked]] On Behalf Of Fernando Gont
> Sent: Wednesday, June 17, 2020 8:21 AM
> To: Alexandre Petrescu <[email-masked]>; Bob Hinden <[email-masked]>
> 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.

---

From: [email-masked]
Date: Wed, 17 Jun 2020 18:35:46 +0200

Fred,

> randomization and constant changing of IP addresses may actual run counter to

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.

Cheers,
Ole

---

From: Bob Hinden <[email-masked]>
Date: Wed, 17 Jun 2020 09:37:29 -0700

Alexandre,

> On Jun 17, 2020, at 4:39 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> link-layer addresses in IPv6 Interface Identifiers”.

The actual text is:

   By default, nodes SHOULD NOT employ IPv6 address generation schemes
   that embed a stable link-layer address in the IID.

It is more than a recommendation.

> necessarily stable.  Windows randomizes some of its MAC addresses.

RFC7721 discusses this, along with what Windows does.

> much is it implemented (linux and freebsd implement random IIDs but of

The length of an Interface ID is not defined in RFC8063.  That is a bigger topic, the current specification is RFC4291 as updated by RFC5952, RFC6052, RFC7136, RFC7346, RFC7371, and RFC8064.

Bob

---

From: Philip Homburg <[email-masked]>
Date: Wed, 17 Jun 2020 18:42:27 +0200

> The case of "same IID with distinct prefixes" is the same as using
> the same IID as the host moves from one network to another. And
> that's quite bad for privacy. PLease see RFC7721.

I think they are quite different. If a host moves between different networks
and keeps the same IID, then the movements of the host can be tracked.

If a host is connected to a subnet that has multiple prefixes, then using
the same IID for all prefixes only has marginally less privacy than
using different IIDs.

That said, in my opinion people who want any kind of control over what
addresses are used, should use DHCPv6 (Or manual/static configuration)

---

From: Philip Homburg <[email-masked]>
Date: Wed, 17 Jun 2020 18:51:53 +0200

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

It should be easy enough to write a document that defines a stable pseudo
random IID.

I wonder however about the political implications of having an IETF document
that argues for embedding tracking identifers in a low level, core IETF
protocol.

---

From: Etienne-Victor Depasquale <[email-masked]>
Date: Wed, 17 Jun 2020 19:23:53 +0200

Bob,

In the case of resource-constrained nodes, such as wireless sensor networks
(WSNs),
the use of algorithms to generate addresses consumes energy.

In my lectures to date (I'm an academic),
I've emphasized that SLAAC in IPv6
requires less energy than automatic address configuration in IPv4.

RFC7217's method of address generation seems to load WSNs unnecessarily,
unless the identity of a sensor is somehow considered important.

Etienne

On Wed, Jun 17, 2020 at 6:37 PM Bob Hinden <[email-masked]> wrote:

> 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,
> >
> The length of an Interface ID is not defined in RFC8063.  That is a bigger
> topic, the current specification is RFC4291 as updated by RFC5952, RFC6052,
> RFC7136, RFC7346, RFC7371, and RFC8064.
>
> Bob
>
>
> >
> > Alex
>

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

---

From: Kerry Lynn <[email-masked]>
Date: Wed, 17 Jun 2020 13:56:34 -0400

On Wed, Jun 17, 2020 at 1:24 PM Etienne-Victor Depasquale <[email-masked]>
wrote:

> Bob,
>
> In the case of resource-constrained nodes, such as wireless sensor
> networks (WSNs),
> RFC 8064 also says:

   In some network technologies and adaptation layers, the use of an IID
   based on a link-layer address may offer some advantages.  For
   example, [RFC6282 <https://tools.ietf.org/html/rfc6282>] allows for
the compression of IPv6 datagrams over
   IEEE 802.15.4-based networks [RFC4944
<https://tools.ietf.org/html/rfc4944>] when the IID is based on the
   underlying link-layer address.

Maintenance of IPv6 sensor networks may trump privacy concerns.  At the
very least, we
might broach the subject of stable randomized 64-bit link-layer identifiers
with IEEE (I am
unaware if any discussions on this topic have occurred).

Kerry

Etienne
>> > necessarily stable.  Windows randomizes some of its MAC addresses..
>>
>> The length of an Interface ID is not defined in RFC8063.  That is a
>> bigger topic, the current specification is RFC4291 as updated by RFC5952,
>> RFC6052, RFC7136, RFC7346, RFC7371, and RFC8064.
>>
>> Bob
>>
>>
>> >
>> > Alex
>>

---

From: Bob Hinden <[email-masked]>
Date: Wed, 17 Jun 2020 11:00:07 -0700

Etienne,

Good to hear that SLACC requires less energy than IPv4 automatic address configuration.

I agree it is a tradeoff when privacy is needed or not.  I suspect that if the calculation to generate a random number is only done very occasionally or only on boot-up, I would think that the energy required isn’t very significant over time.

Bob

> On Jun 17, 2020, at 10:23 AM, Etienne-Victor Depasquale <[email-masked]> wrote:
> 
> Bob,
> 
> In the case of resource-constrained nodes, such as wireless sensor networks (WSNs),

---

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

On 17/6/20 13:17, Templin (US), Fred L wrote:
> privacy is ALWAYS a required property.

The assumption is that you fail on the safe side -- that's the essence 
of RFC8064.

> However, there are cases where address

FWIW, RFC7217 produces "stable per network" as that's what is typically 
a somewhat "sane" operational requirement. Normally, at the time you 
require constant (across networks) IIDs, you have:

1) ++evilness, xor,
2) if you don't operate the target networks, you cannot enforce that 
(think networks requiring managed address configuration via DHCPv6), xor,
3) You do not need to rely on this, and you could have the hosts report 
the addresses themselves (e.g., dyn dns updates), xor,
4) If you do operate the target networks, you probably can track the 
nodes themselves (e.g., via non-random mac addresses), unless the hosts 
intentionally don't want that (e.g., they randomize their mac addresses)

Thanks,

---

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

> the same IID for all prefixes only has marginally less privacy than

Well, it does allow correlation of network activities across addresses. 
In a way, that's kind of the same as when a host moves across networks.

+1

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 17 Jun 2020 15:30:51 -0400

> > addresses are used, should use DHCPv6 (Or manual/static configuration)

   Of course the caveat there with unmanaged network and SOHO and Mobile
where manual or DHCPV6 is not possible or viable.  In those cases SLAAC is
preferred, but then we have the crux of issue and the decision tree on
privacy random IID and it’s overhead if it’s not necessary versus modified
EUI64.  Based on decision 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.

-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: Philip Homburg <[email-masked]>
Date: Wed, 17 Jun 2020 23:54:07 +0200

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

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 17 Jun 2020 20:04:05 -0400

> But I doubt that a low power IoT device would share a wifi-link with an

   I used use cases where the individual or unmanaged networks in those
cases may not have the expertise to setup dhcpv6

> device is probably insecure and should not be connect to the internet

   I don’t have the expertise on energy consumption issues on mobile but it
did appear from the thread that issues due exist with random over stable
IID.  Technically speaking I don’t understand why.

*Gyan Mishra*

---

From: Etienne-Victor Depasquale <[email-masked]>
Date: Thu, 18 Jun 2020 08:29:19 +0200

Philip,

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

I haven't got any data to make a case. What I can see is a WSN scenario,
with some features in it, as follows.

One important operating principle with WSNs is to prolong lifetime.
When a node turns off, its loss may cause network-wide effects, like RPL
DODAG tree re-formation.

Sensors are output devices, oriented towards their border router for access
to the Internet.
Is it fair to say that they're single-purpose devices, supporting no
(little?) more than a RESTful interface to their data acquisition?
I think so.

Does it make sense to load sensors with generation of semantically opaque
interface identifiers?
Yes - but only after understanding its impact through a network-scoped
study of WSN lifetime.

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

---

From: Ole Troan <[email-masked]>
Date: Thu, 18 Jun 2020 08:37:28 +0200

> On 18 Jun 2020, at 02:04, Gyan Mishra <[email-masked]> wrote:
> 
>    I used use cases where the individual or unmanaged networks in those cases may not have the expertise to setup dhcpv6 

There’s nothing intrinsic in the dhcpv6 protocol that prohibits it from being automatically set up and configured. I believe homenet did this. On the first-hop router you could eg run a dhcp server instance  per link. It’s only if you want a centralized dhcp service with relays it becomes more complicated.  

Cheers 
Ole

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 18 Jun 2020 07:38:46 +0000

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
> From: ipv6 <[email-masked]> On Behalf Of Templin (US), Fred L
> Sent: mercredi 17 juin 2020 18:18
> To: Fernando Gont <[email-masked]>; Alexandre Petrescu
> <[email-masked]>; Bob Hinden <[email-masked]>
> 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.
> 
> randomization and constant changing of IP addresses may actual run counter
> to operational objectives.
> 
> Thanks - Fred
> 
> > 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.
> > > RFC8064 says "this document [...] recommends against embedding
> > > stable link-layer addresses in IPv6 Interface Identifiers".
> > >

---

From: Mark Smith <[email-masked]>
Date: Thu, 18 Jun 2020 17:50:33 +1000

On Thu, 18 Jun 2020, 16:30 Etienne-Victor Depasquale, <[email-masked]>
wrote:

> I haven't got any data to make a case.. What I can see is a WSN scenario,
> Sensors are output devices, oriented towards their border router for
> access to the Internet.

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.

Regards,
Mark.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 18 Jun 2020 10:20:20 +0200

> 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 don't understand the behavior of first picking SLAAC over DHCPv6 and then
trying to modify SLAAC to do something it is not designed to do.

If you want to have stable addresses with the ability to replace hardware,
use DHCPv6. It is meant to provide this mapping.

If you want to group devices in address ranges that are easy to identify,
DHCPv6 can also do this.

SLAAC was meant for the unmanaged situation where devices can generate addresses
without any outside support.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 18 Jun 2020 08:41:08 +0000

Hello Phil

> From: [email-masked] <[email-masked]>
> On Behalf Of Philip Homburg
> Sent: jeudi 18 juin 2020 10:20
> To: [email-masked]
> Cc: Pascal Thubert (pthubert) <[email-masked]>
> Subject: Re: [EXTERNAL] Re: 64bit MAC addresses and SLAAC
> 
> > 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).
> >
> > 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

It does not matter what our preconception is of what SLAAC is for. What matters is what it can do. 

In the case of IPv6 over IEEE 802.15.4, there is a centralized assignment of the short MAC address, and then SLAAC can derive the IP address from that MAC address to enable stateless compression.
Nothing wrong with that if that serves the purpose.

> If you want to have stable addresses with the ability to replace hardware, use
> DHCPv6. It is meant to provide this mapping.

DHCP is an extra round trip. Some standards accept that cost (e.g., Wi-SUN) some will not. Also, in the Wi-SUN case, the device is identified separately with certs and all, and the IPv6 address is assigned later, which is probably cleaner and certainly more expensive.
When people want the address to be known by the management system and associated to the role / position of the device, the easiest is usually the pre-provisioning, and forcing DHCP in that picture is a hard sell. 

Keep safe,

Pascal

---

From: Philip Homburg <[email-masked]>
Date: Thu, 18 Jun 2020 11:43:24 +0200

> In the case of IPv6 over IEEE 802.15.4, there is a centralized
> assignment of the short MAC address, and then SLAAC can derive the
> IP address from that MAC address to enable stateless compression.

If the MAC address is dynamically assigned by the network, then we can
assume that having the IID based on the MAC address is safe from the point
of view of tracking.

This is very far from the original concept of using a globally unique MAC
address as IID.

We should avoid using tracking identifiers as IIDs. However, that does not
rule out using other dynamically generated identifiers as part of IIDs.

> When people want the address to be known by the management
> system and associated to the role / position of the device, the
> easiest is usually the pre-provisioning, and forcing DHCP in that
> picture is a hard sell.

How is pre-provisioning related to SLAAC? Lot's of servers get addresses from
out of band configuration systems.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 18 Jun 2020 10:03:18 +0000

Hello Phil

> Sent: jeudi 18 juin 2020 11:43
> To: [email-masked]
> > assignment of the short MAC address, and then SLAAC can derive the IP
> > address from that MAC address to enable stateless compression.
> assume that having the IID based on the MAC address is safe from the point of
> view of tracking.
> 
> We should avoid using tracking identifiers as IIDs. However, that does not rule
> out using other dynamically generated identifiers as part of IIDs.

We agree

> 
> > When people want the address to be known by the management system and
> > associated to the role / position of the device, the easiest is
> > usually the pre-provisioning, and forcing DHCP in that picture is a
> > hard sell.
> 

Who said it was? 

We agree again...

Pascal

---

From: Philip Homburg <[email-masked]>
Date: Thu, 18 Jun 2020 12:13:44 +0200

>In a way, that's kind of the same as when a host moves across networks.

My home network has a number of prefixes. From reverse DNS you can easily
figure out that they are the same. How does it help me to have different IIDs
for different prefixes?

Same applies to any org that tries to renumber.

I'm not saying that anything needs to be changed. Just that we should not
oversell the privacy benefits.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 18 Jun 2020 06:40:40 -0300

Hi, Pascal,

> There are cases where anonymity is entirely undesirable.

The key issue here is what the defaults should be. In the context of
RFC7258, I think it would be hard to make a case for privacy-insensible
algorithms for default configurations.

> treatment if the IPv6 address derives from the MAC. 

1) Embedding MAC adresses in IIDs is kind of a kludge. Yes, it made 
sense when borrowed from IPX ages ago... but the context was quite 
different.

2) From an interoperability standpoint, you should only rely on the IID 
being unique.

> Note that this

I don't mind when this sort of thing is employed for specific scenarios 
such as the one you describe. However, it would seem seem to me that if 
you really need the addresses to embed the underlying link-layer address 
so that you can compress the IPv6 header and keep the associated 
overhead at a decent level... one might (unfortunately) want to 
reconsider the extent to which IPv6 is really applicable here, or 
whether some sort of gateway that bridges a low-overhead simple protocol 
with the rest of the network might be a better approach.

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

RFC8064 makes a recommendation for the default algorithm for generating 
stable addresses. General purpose systems need some guidance recarding 
how to generate the IIDs, are what considerations should be had when 
developing such an algorithm.

As all "SHOULDs/SHOULD NOTs", it's okay to not follow the advice if you 
have really good reasons to and/or know better what you are doing.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 18 Jun 2020 07:29:49 -0300

> figure out that they are the same. How does it help me to have different IIDs

different-per-prefix IIDs cannot, of course, mitigate information 
leakages that happens elsewhere.

FWIW, I use about 7+ GUA prefixes at home, with no reverse DNS mappings. 
RFC7217 prevents activity correlation  among them. Traditional SLAAC 
IIDs would have made it trivial.

> oversell the privacy benefits.

As noted in many discussions we have had on the topic, ipv6 iid 
"randomization" mitigates correlation at the network level. In your 
particular scenario, the information leakage happens elsewhere.

i.e., if you want to mitigate activity correlation as a whole, doing 
something sensible for ipv6 addresses is one bit of the "puzzle".

Thanks,

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 18 Jun 2020 10:58:13 +0000

> with the rest of the network might be a better approach.

I read that you're wondering if a particular domain should enjoy the benefits of IPv6 because of a preconception on how to form IIDs coming from another domain. Is that your intent?

Pascal

"
Ian Malcolm: That is one big pile of shit.

Ian Malcolm: Life will find a way.

Ian Malcolm: Life finds a way.

John Hammond: Welcome, to Jurassic Park!

Alan Grant: Life found a way!
"

---

From: Mark Smith <[email-masked]>
Date: Thu, 18 Jun 2020 22:04:23 +1000

> oversell the privacy benefits.

I don't think we are. However, we also don't want to fall into the
trap of "it's not perfect, so let's do nothing". We're limited to
within our problem space, however we should try to provide the best
privacy we can without impacting end-user experience, or at least
limit impacting end-user experience to only when it is necessary to
try to assure privacy.

Similar to security, I think privacy is a weakest link problem. We
don't want IPv6 addresses to be the weakest link within the set of
device, OS or application session identifiers that reduce a device's
end-user's privacy.

For end-user devices, IPv6 addresses with privacy properties by
default is the best choice because typical end-users are not going to
have any idea what an IPv6 address is, let alone be able to properly
evaluate the privacy implications of whether or not they should have
IPv6 privacy addresses.

Regards,
Mark.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 18 Jun 2020 15:47:46 +0200

>> https://tools.ietf.org/html/draft-gont-numeric-ids-sec-considerations

Using same IIDs in several interfaces might be a bad idea some times but 
good elsewhere.

For example, when I am manually configuring two interfaces of the same 
router it is easy for me to know I just need to change one or two hex 
digits in the subnet number.  It is much faster.

It is a matter of convenience to humans, in some contexts.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 18 Jun 2020 16:24:32 +0200

Le 17/06/2020 à 23:54, Philip Homburg a écrit :
>> Of course the caveat there with unmanaged network and SOHO and
>> Mobile where manual or DHCPV6 is not possible or viable.
> 
> But I doubt that a low power IoT device would share a wifi-link with
> an Android device.
> 
>> 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

I am not sure which crypto function is used in our (well, a colleague
programmer's) linux kernel code to generate variable length IIDs.  We
generate a 128bit random number with a crypto function and then pick the
necessary bits to form an IID from it and from the non-64 prefix from
PIO from RA.

However, by doing that we become fully dependent on that crypto function
(say it's called 'C') to generate an address.

If that 'C' is not seeded well enough, or has licenses on it, or is
IPRed, or is not open source, or bleeds when attacked by a
distributed.net lucky PC, or is not resisting quantum attacks after
tomorrow, or was not fully tested against endianness on this new IoT
platform, or is too slow, or simply does not compile there - then we're
at risk.

Alex

> 
> I cannot imagine that computing 2 SHA2 hashes has a significant
> amount of energy use compared to link attachment and duplicate
> address detection.
> 
> 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 [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 18 Jun 2020 16:26:05 +0200

Le 18/06/2020 à 08:29, Etienne-Victor Depasquale a écrit :
> I haven't got any data to make a case.. What I can see is a WSN 
> scenario, with some features in it, as follows.
> 
> Does it make sense to load sensors with generation of semantically 
> opaque interface identifiers?
> by implementing access control to the nodes at the (mains-powered) 
> border router.

The alternative makes sense.

Alex

> 
> Etienne
> 
> On Wed, Jun 17, 2020 at 11:54 PM Philip Homburg 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
> 
>     Mobile
>     [email-masked] <mailto:[email-masked]>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 18 Jun 2020 16:29:29 +0200

Le 18/06/2020 à 09:50, Mark Smith a écrit :
> 
> 
> On Thu, 18 Jun 2020, 16:30 Etienne-Victor Depasquale, <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Philip,
> 
>     I haven't got any data to make a case... What I can see is a WSN
>     When a node turns off, its loss may cause network-wide effects, like
>     RPL DODAG tree re-formation.
> 
>     Yes - but only after understanding its impact through a
>     network-scoped study of WSN lifetime.
> 
> 
> 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.
> 
> 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.

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

>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>         amount

---

From: Fernando Gont <[email-masked]>
Date: Thu, 18 Jun 2020 08:26:48 -0300

> I read that you're wondering if a particular domain should enjoy the benefits of IPv6 because of a preconception on how to form IIDs coming from another domain. Is that your intent?

No.

I'm saying that there's no reason (requirement) for which the IPv6 IID 
should embed the underlying link-layer (for instance, see RFC7136). 
Unlike IPX, IPv6 implements Neighbor Discovery, so the only marginal 
benefit of embedding the link-layer address in the IID is that the 
resulting address is likely to be unique (yet we still have DAD).

Since the generation of an IID is a host local policy, reliance on the 
IID being any specific value is questionable.

If such reliance is because the overhead is simply unacceptable, then 
yes, I believe it is a valid question whether IPv6 is the right protocol 
for whatever device/technology needs such compression to keep the 
overhead track-table.

YI also agree that there may be valid reasons for which, even if IPv6 
was not the best fit for your application, but you might still want to 
use it, and hence resort to the hacks such as "header compression".

The fact that such hack somewhat introduces a requirement that is not 
present anywhere in the ipv6 address architecture (the IID can be 
anything, since you could e.g. manually configure your addresses, they 
could be dhcpv6-leased, etc.), should be a hint in that direction.

Much of what I've seem to remember seeing in the 6lo et al area seem to 
be tricks to somewhat make IPv6 tractable for the "constrained" scenarios.

Anyway, believe the IID generation should be the least of your concerns 
here: at the end of the day there's a recommendation (RFC8064) for the 
general case... but you're free to override it. I seem to remember there 
was a proposal by Dave Thaler in this area, meant for constrained nodes, 
too.

Thanks,

---

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

> If that 'C' is not seeded well enough, or has licenses on it, or
> is IPRed, or is not open source, or bleeds when attacked by a
> tomorrow, or was not fully tested against endianness on this new
> IoT platform, or is too slow, or simply does not compile there -
> then we're at risk.

You always write an RFC that discusses which function to use for generating
IIDs.

In this context, SHA2 is safe against quantum attacks. You do need a way
of providing a device with a stable secret. However, you probably need that
for any kind of security. If you cannot do that, then it is probably better
to avoid connecting the device to the internet.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 18 Jun 2020 16:23:25 +0000

> From: Fernando Gont <[email-masked]>
> Sent: jeudi 18 juin 2020 13:27
> To: Pascal Thubert (pthubert) <[email-masked]>; Templin (US), Fred L
> <[email-masked]>; Kerry Lynn <[email-masked]>
> >>> antinomic for burn-in MAC addresses; but there are also standards
> >> I don't mind when this sort of thing is employed for specific
> >> scenarios such as the one you describe. However, it would seem seem
> >> to me that if you really need the addresses to embed the underlying
> >> link-layer address so that you can compress the IPv6 header and keep
> >> the associated overhead at a decent level... one might
> >> (unfortunately) want to reconsider the extent to which IPv6 is really
> >> applicable here, or whether some sort of gateway that bridges a
> >> low-overhead simple protocol with the rest of the network might be a
> better approach.
> >
> > I read that you're wondering if a particular domain should enjoy the benefits
> of IPv6 because of a preconception on how to form IIDs coming from another
> domain. Is that your intent?
> 
> No.
> 
> I'm saying that there's no reason (requirement) for which the IPv6 IID should
> embed the underlying link-layer (for instance, see RFC7136).
> Unlike IPX, IPv6 implements Neighbor Discovery, so the only marginal benefit
> of embedding the link-layer address in the IID is that the resulting address is
> likely to be unique (yet we still have DAD).
> 
> Since the generation of an IID is a host local policy, reliance on the IID being
> any specific value is questionable.
> 
> If such reliance is because the overhead is simply unacceptable, then yes, I
> believe it is a valid question whether IPv6 is the right protocol for whatever
> device/technology needs such compression to keep the overhead track-table.
> 
> YI also agree that there may be valid reasons for which, even if IPv6 was not
> the best fit for your application, but you might still want to use it, and hence
> resort to the hacks such as "header compression".
> 
> The fact that such hack somewhat introduces a requirement that is not present
> anywhere in the ipv6 address architecture (the IID can be anything, since you
> could e.g. manually configure your addresses, they could be dhcpv6-leased,
> etc.), should be a hint in that direction.
> 
> Much of what I've seem to remember seeing in the 6lo et al area seem to be
> tricks to somewhat make IPv6 tractable for the "constrained" scenarios.
> 
> general case... but you're free to override it. I seem to remember there was a
> proposal by Dave Thaler in this area, meant for constrained nodes, too.
> 
Works for me, Fernando 😊

Pascal

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 18 Jun 2020 23:08:00 +0200

> If such reliance is because the overhead is simply unacceptable, then yes, I believe it is a valid question whether IPv6 is the right protocol for whatever device/technology needs such compression to keep the overhead track-table.

Valid question indeed.  The answer may very well be yes.

> YI also agree that there may be valid reasons for which, even if IPv6 was not the best fit for your application, but you might still want to use it, and hence resort to the hacks such as "header compression".

Header compression is not a “hack”.  Jeez.

Seriously, I don’t know where to start.

Even if there still is no Wikipedia page for header compression yet (I’ve been using that as in intro to talks about the subject for quite a while), that is not an excuse for not getting educated about the 30 years of history that header compression has in IP, starting with Van Jacobson’s RFC 1144.

> The fact that such hack somewhat introduces a requirement that is not present anywhere in the ipv6 address architecture (the IID can be anything, since you could e.g. manually configure your addresses, they could be dhcpv6-leased, etc.), should be a hint in that direction.

It is not a requirement; we designed things carefully so it isn’t.
But using the redundancy does supply some additional efficiency, so some deployments may want to use that efficiency to stay within a (technical) budget.
(The privacy-relevant ones don’t have that luxury, of course.)

> Much of what I've seem to remember seeing in the 6lo et al area seem to be tricks to somewhat make IPv6 tractable for the "constrained" scenarios.

Yes, that is the point.
It may not be your area of work, but that doesn’t make it invalid or “tricks” or “a hack”.
(Insert a couple of expletives here, because you have been around for a while and could know all this.)

> Anyway, believe the IID generation should be the least of your concerns here: at the end of the day there's a recommendation (RFC8064) for the general case... but you're free to override it. I seem to remember there was a proposal by Dave Thaler in this area, meant for constrained nodes, too.

Yes.  RFC 8065, and the number is *not* a coincidence.

Grüße, Carsten

---

From: Mark Smith <[email-masked]>
Date: Fri, 19 Jun 2020 08:03:51 +1000

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

> <snip>

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.

> >         Administrative Requests:

---

From: Etienne-Victor Depasquale <[email-masked]>
Date: Fri, 19 Jun 2020 11:18:16 +0200

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 <[email-masked]> wrote:

>
>
> On Fri, 19 Jun 2020, 00:30 Alexandre Petrescu, <
> [email-masked]> wrote:
>
>>
>>
> 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.
>
> only application problems..
>
> Regards,
> Mark.
>
>
>
>> >     [email-masked] <mailto:[email-masked] <ipv6@ietf..org>>

---

From: Mark Smith <[email-masked]>
Date: Fri, 19 Jun 2020 20:20:33 +1000

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

>>> >         I also wonder, a device that cannot afford a couple SHa2
>>> hashes?
>>> >         Then that

---

From: Etienne-Victor Depasquale <[email-masked]>
Date: Fri, 19 Jun 2020 13:11:07 +0200

> 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 <[email-masked]> wrote:

>>> 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
>>>> >          >   Of course the caveat there with unmanaged network and
>>>> SOHO
>>>> >         and Mobile
>>>> >         But I doubt that a low power IoT device would share a
>>>> wifi-link
>>>> >         with an
>>>> >         Android device.
>>>> >
>>>> >          >    issue and the decision tree on privacy random IID and
>>>> its
>>>> >         overhead
>>>> >         of energy use compared to link attachment and duplicate
>>>> address
>>>> >         detection.
>>>> >