Should off-the-shelf devices use a unique AppEUI/JoinEUI for each device?

[arjanvanb (Arjan)]

So far, I very much felt that off-the-shelf 1.0.x devices should have a unique AppEUI (and DevEUI) for each device. Quoting myself:

@arjanvanb

From the LoRaWAN specifications:

6.1.2 Application identifier (AppEUI)

The AppEUI is a global application ID in IEEE EUI64 address space that uniquely identifies the entity able to process the JoinReq frame.

By definition, an EUI-64 address should be unique. In this case: unique per application, but [the manufacturer] should not expect customers to share an application, so each off-the-shelf device should have its own unique AppEUI (and DevEUI).

In real life, at least on TTN things seem to work if a non-unique AppEUI is shared among multiple devices, registered by different users. (Also a single TTN user can use the same AppEUI in multiple applications in TTN Console, at least in V2.) Again quoting myself, while I was quoting myself:

@arjanvanb

I’m a bit surprised that multiple users can apparently add the same non-unique AppEUI to TTN Console, but it seems TTN only uses the combination of AppEUI and DevEUI:

@arjanvanb

Hylke wrote on Slack:

@htdvisser [Jan 11th 2019 4:24 PM]

We use the AppEUI+DevEUI combination as identifier for a device, so as long as you use different AppEUIs for devices with the same DevEUI, you should be fine for now (but you may encounter problems in v3 if you would use LoRaWAN 1.1 ReJoinRequests)

Things might be different for other networks, so I’d just make sure the AppEUI and DevEUI are unique (and comply to the rules of an EUI-64, so are either purchased or crafted using specific rules).

So it seems at least TTN V2 can handle sharing an AppEUI (though someone reported that programming a new, unique AppEUI fixed their problems). And we’ve seen quite a few devices use a single or non-registered AppEUI. (Like Dragino LHT65 and LGT92, RadioBridge, Nke Watteco, Axioma Qalcosonic, …?)

But if things work, then why did the LoRaWAN specifications even bother about defining the AppEUI? Surely the network servers could have used just the DevEUI and MIC to find the right configuration. This makes me feel that things work because of implementation choices, despite the devices not being compliant.

Any thoughts, opinions?