ieee802154: Fix generation of random EUI-64 addresses.
RFC PATCH 1/2 ieee802154: Fix generation of random EUI-64 addresses.
Currently, ieee802154_random_extended_addr() has a 50% chance of generating a group (multicast) address, while this function is used for generating station addresses (which can't be group addresses) for interfaces that don't have a hardware-provided address.
Also, in case get_random_bytes() generates the EUI-64 address 00:00:00:00:00:00:00:00 (extremely unlikely), which is an invalid address, ieee802154_random_extended_addr() reacts by changing it to 01:00:00:00:00:00:00:00, which is an invalid station address as well, as it is a group address.
This patch changes the address generation procedure to grab eight random bytes, treat that as an EUI-64, and then clear the Group address bit and set the Locally Administered bit, which is in line with how eth_random_addr() generates random EUI-48s.
--- include/linux/ieee802154.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
include/linux/ieee802154.h +3 -3
@@ -244,9 +244,9 @@ static inline void ieee802154_random_extended_addr(__le64 *addr) {get_random_bytes (addr,IEEE802154_EXTENDED_ADDR_LEN ); -/* toggle some bit if we hit an invalid extended addr */ -if (!ieee802154_is_valid_extended_addr (*addr)) - ((u8 *)addr)[IEEE802154_EXTENDED_ADDR_LEN -1 ] ^=0x01 ; +/* clear the group bit, and set the locally administered bit */ + ((u8 *)addr)[IEEE802154_EXTENDED_ADDR_LEN -1 ] &= ~0x01 ; + ((u8 *)addr)[IEEE802154_EXTENDED_ADDR_LEN -1 ] |=0x02 ; }#endif /* LINUX_IEEE802154_H */
Signature · 1 line
2.4.1
Alexander Aring
maintainerQuoted 11 lines · Lennert Buytenhek
Currently,
ieee802154_random_extended_addr()has a 50% chance of generating a group (multicast) address, while this function is used for generating station addresses (which can't be group addresses) for interfaces that don't have a hardware-provided address.Also, in case
get_random_bytes()generates the EUI-64 address 00:00:00:00:00:00:00:00 (extremely unlikely), which is an invalid address,ieee802154_random_extended_addr()reacts by changing it to 01:00:00:00:00:00:00:00, which is an invalid station address as well, as it is a group address.
Quoted 5 lines
This patch changes the address generation procedure to grab eight random bytes, treat that as an EUI-64, and then clear the Group address bit and set the Locally Administered bit, which is in line with how
eth_random_addr()generates random EUI-48s.
This is one thing which I asked myself already. If the group address comming from EUI-64 standard or not. What I can say is that the 802.15.4 MAC layer doesn't care about this bit and we don't have _any_ multicast functionality.
What you try to do is to map ethernet MAC functionality to 802.15.4 MAC. The 802.15.4 have no special bits inside the EUI64 which indicates something. Our multicast functionality is done by a broadcast (done by short address, which is currently indicate by a 0xff..ff extended addr, because IPv6 can't deal at the moment deal with two types of mac address types.)
What I always find is this document [0]. Which describes that the 0x00..00 and 0xff...ff are invalid. (And a node should really not use 0xff..ff since we have the workaround with IPv6 for broadcast).
If we would have such bit, then we also need to implement [1], which generates the multicast address according the IPv6 address. At the moment we get the dev->broadcast address which is correct, because we don't have multicast functionality.
I don't ack this patch, because I don't see at the moment that this is wrong. Maybe I don't get it. If IPv6 checks on this bit and indicates a multicast on L2 _then_ we should change it, but I don't think that IPv6 do that.
- Alex
[0] http://standards.ieee.org/develop/regauth/tut/eui64.pdf
[1] http://lxr.free-electrons.com/source/net/ipv6/ndisc.c#L264
Quoted 44 lines · Alexander Aring
Quoted 11 lines
Currently,
ieee802154_random_extended_addr()has a 50% chance of generating a group (multicast) address, while this function is used for generating station addresses (which can't be group addresses) for interfaces that don't have a hardware-provided address.Also, in case
get_random_bytes()generates the EUI-64 address 00:00:00:00:00:00:00:00 (extremely unlikely), which is an invalid address,ieee802154_random_extended_addr()reacts by changing it to 01:00:00:00:00:00:00:00, which is an invalid station address as well, as it is a group address.Quoted 4 lines
This patch changes the address generation procedure to grab eight random bytes, treat that as an EUI-64, and then clear the Group address bit and set the Locally Administered bit, which is in line with how
eth_random_addr()generates random EUI-48s.This is one thing which I asked myself already. If the group address comming from EUI-64 standard or not. What I can say is that the 802.15.4 MAC layer doesn't care about this bit and we don't have _any_ multicast functionality.
What you try to do is to map ethernet MAC functionality to 802.15.4 MAC. The 802.15.4 have no special bits inside the EUI64 which indicates something. Our multicast functionality is done by a broadcast (done by short address, which is currently indicate by a 0xff..ff extended addr, because IPv6 can't deal at the moment deal with two types of mac address types.)
What I always find is this document [0]. Which describes that the 0x00..00 and 0xff...ff are invalid. (And a node should really not use 0xff..ff since we have the workaround with IPv6 for broadcast).
If we would have such bit, then we also need to implement [1], which generates the multicast address according the IPv6 address. At the moment we get the
dev->broadcastaddress which is correct, because we don't have multicast functionality.I don't ack this patch, because I don't see at the moment that this is wrong. Maybe I don't get it. If IPv6 checks on this bit and indicates a multicast on L2 _then_ we should change it, but I don't think that IPv6 do that.
Quoted 4 lines
- Alex
[0] http://standards.ieee.org/develop/regauth/tut/eui64.pdf
[1] http://lxr.free-electrons.com/source/net/ipv6/ndisc.c#L264
Your [0] document states that EUI-64 addresses start with an OUI, and the structure of the OUI is documented in this document:
https://standards.ieee.org/develop/regauth/tut/eui.pdf
Page 4 of this document shows that every OUI(/CID) contains the Universal/Local and Individual/Group address bits, and this is true no matter whether this OUI is part of an EUI-48 or an EUI-64.
Also compare your [0] with this document:
http://standards.ieee.org/develop/regauth/tut/eui48.pdf
And note how neither the EUI-48 nor the EUI-64 PDFs talk about group addresses -- this is because an EUI-{48,64} contains an OUI, and the OUI contains the scope/group bits, and so the documents explaining the EUI-{48,64} format are not the right place to discuss those bits, although they exist both in EUI-48 and in EUI-64 addresses.
Just the fact that 802.15.4 spec doesn't talk about multicast doesn't suddenly redefine the EUI-64 group bit as just another unicast address bit, in my humble opinion, but this is what Linux is currently doing.
From a hardware point of view, multicast packets should never be
ACKed, so there is no need for the hardware to be aware of the active multicast addresses on this interface per se. (We could theoretically pass the multicast address list for the interface to the hardware to allow doing frame filtering in hardware, but this does not affect operational correctness.)
Whether we should be using EUI-64 group addresses on the "wire" for 802.15.4 for multicast (IPv6) traffic is another question, but using EUI-64 group addresses as station addresses just because the link layer doesn't define multicast functionality is wrong from my point of view.
Quoted 79 lines · Lennert Buytenhek
Quoted 44 lines
Quoted 11 lines
Currently,
ieee802154_random_extended_addr()has a 50% chance of generating a group (multicast) address, while this function is used for generating station addresses (which can't be group addresses) for interfaces that don't have a hardware-provided address.Also, in case
get_random_bytes()generates the EUI-64 address 00:00:00:00:00:00:00:00 (extremely unlikely), which is an invalid address,ieee802154_random_extended_addr()reacts by changing it to 01:00:00:00:00:00:00:00, which is an invalid station address as well, as it is a group address.Quoted 4 lines
This patch changes the address generation procedure to grab eight random bytes, treat that as an EUI-64, and then clear the Group address bit and set the Locally Administered bit, which is in line with how
eth_random_addr()generates random EUI-48s.This is one thing which I asked myself already. If the group address comming from EUI-64 standard or not. What I can say is that the 802.15.4 MAC layer doesn't care about this bit and we don't have _any_ multicast functionality.
What you try to do is to map ethernet MAC functionality to 802.15.4 MAC. The 802.15.4 have no special bits inside the EUI64 which indicates something. Our multicast functionality is done by a broadcast (done by short address, which is currently indicate by a 0xff..ff extended addr, because IPv6 can't deal at the moment deal with two types of mac address types.)
What I always find is this document [0]. Which describes that the 0x00..00 and 0xff...ff are invalid. (And a node should really not use 0xff..ff since we have the workaround with IPv6 for broadcast).
If we would have such bit, then we also need to implement [1], which generates the multicast address according the IPv6 address. At the moment we get the
dev->broadcastaddress which is correct, because we don't have multicast functionality.I don't ack this patch, because I don't see at the moment that this is wrong. Maybe I don't get it. If IPv6 checks on this bit and indicates a multicast on L2 _then_ we should change it, but I don't think that IPv6 do that.
Quoted 4 lines
- Alex
[0] http://standards.ieee.org/develop/regauth/tut/eui64.pdf
[1] http://lxr.free-electrons.com/source/net/ipv6/ndisc.c#L264Your [0] document states that EUI-64 addresses start with an OUI, and the structure of the OUI is documented in this document:
https://standards.ieee.org/develop/regauth/tut/eui.pdf
Page 4 of this document shows that every OUI(/CID) contains the Universal/Local and Individual/Group address bits, and this is true no matter whether this OUI is part of an EUI-48 or an EUI-64.
Also compare your [0] with this document:
http://standards.ieee.org/develop/regauth/tut/eui48.pdf
And note how neither the EUI-48 nor the EUI-64 PDFs talk about group addresses -- this is because an EUI-{48,64} contains an OUI, and the OUI contains the scope/group bits, and so the documents explaining the EUI-{48,64} format are not the right place to discuss those bits, although they exist both in EUI-48 and in EUI-64 addresses.
Just the fact that 802.15.4 spec doesn't talk about multicast doesn't suddenly redefine the EUI-64 group bit as just another unicast address bit, in my humble opinion, but this is what Linux is currently doing.
Quoted 1 line
From a hardware point of view, multicast packets should never be
ACKed, so there is no need for the hardware to be aware of the active multicast addresses on this interface per se. (We could theoretically pass the multicast address list for the interface to the hardware to allow doing frame filtering in hardware, but this does not affect operational correctness.)
Quoted 5 lines
Whether we should be using EUI-64 group addresses on the "wire" for 802.15.4 for multicast (IPv6) traffic is another question, but using EUI-64 group addresses as station addresses just because the link layer doesn't define multicast functionality is wrong from my point of view.
Appendix A in RFC4291 also seems to confirm that the scope/group bits are an inherent part of any EUI-64 address:
http://tools.ietf.org/html/rfc4291#page-20
Alexander Aring
maintainerQuoted 51 lines · Lennert Buytenhek
Quoted 44 lines · Alexander Aring
Quoted 11 lines
Currently,
ieee802154_random_extended_addr()has a 50% chance of generating a group (multicast) address, while this function is used for generating station addresses (which can't be group addresses) for interfaces that don't have a hardware-provided address.Also, in case
get_random_bytes()generates the EUI-64 address 00:00:00:00:00:00:00:00 (extremely unlikely), which is an invalid address,ieee802154_random_extended_addr()reacts by changing it to 01:00:00:00:00:00:00:00, which is an invalid station address as well, as it is a group address.Quoted 4 lines
This patch changes the address generation procedure to grab eight random bytes, treat that as an EUI-64, and then clear the Group address bit and set the Locally Administered bit, which is in line with how
eth_random_addr()generates random EUI-48s.This is one thing which I asked myself already. If the group address comming from EUI-64 standard or not. What I can say is that the 802.15.4 MAC layer doesn't care about this bit and we don't have _any_ multicast functionality.
What you try to do is to map ethernet MAC functionality to 802.15.4 MAC. The 802.15.4 have no special bits inside the EUI64 which indicates something. Our multicast functionality is done by a broadcast (done by short address, which is currently indicate by a 0xff..ff extended addr, because IPv6 can't deal at the moment deal with two types of mac address types.)
What I always find is this document [0]. Which describes that the 0x00..00 and 0xff...ff are invalid. (And a node should really not use 0xff..ff since we have the workaround with IPv6 for broadcast).
If we would have such bit, then we also need to implement [1], which generates the multicast address according the IPv6 address. At the moment we get the
dev->broadcastaddress which is correct, because we don't have multicast functionality.I don't ack this patch, because I don't see at the moment that this is wrong. Maybe I don't get it. If IPv6 checks on this bit and indicates a multicast on L2 _then_ we should change it, but I don't think that IPv6 do that.
Quoted 9 lines
Your [0] document states that EUI-64 addresses start with an OUI, and the structure of the OUI is documented in this document:
https://standards.ieee.org/develop/regauth/tut/eui.pdf
Page 4 of this document shows that every OUI(/CID) contains the Universal/Local and Individual/Group address bits, and this is true no matter whether this OUI is part of an EUI-48 or an EUI-64.
yes this makes sense and one argument to change it to your behaviour.
Quoted 10 lines
Also compare your [0] with this document:
http://standards.ieee.org/develop/regauth/tut/eui48.pdf
And note how neither the EUI-48 nor the EUI-64 PDFs talk about group addresses -- this is because an EUI-{48,64} contains an OUI, and the OUI contains the scope/group bits, and so the documents explaining the EUI-{48,64} format are not the right place to discuss those bits, although they exist both in EUI-48 and in EUI-64 addresses.
Quoted 4 lines
Just the fact that 802.15.4 spec doesn't talk about multicast doesn't suddenly redefine the EUI-64 group bit as just another unicast address bit, in my humble opinion, but this is what Linux is currently doing.
The 802.15.4 spec doesn't also say any words about that the "extended address" is an EUI-64 address. 6LoWPAN RFC says it should handled like a EUI-64 [1]. General question is "Is the extended-address in 802.15.4 really meaning an EUI-64 address?". Sorry for this newbie question, but this is what I am asking myself now.
What I see is that the extended-addr is described as "The 64-bit (IEEE) address assigned to the device." Which says to me it's an EUI-64, or?
But then this means 0x00..00 and 0xff..ff are also valid, but IPv6 can't deal with the 0x00..00.
Quoted 6 lines
From a hardware point of view, multicast packets should never be ACKed, so there is no need for the hardware to be aware of the active multicast addresses on this interface per se. (We could theoretically pass the multicast address list for the interface to the hardware to allow doing frame filtering in hardware, but this does not affect operational correctness.)
So then we should also add a check of this bit at [0]? Then set the ackreq bit to 0 if the bit is set?
Quoted 6 lines
Whether we should be using EUI-64 group addresses on the "wire" for 802.15.4 for multicast (IPv6) traffic is another question, but using EUI-64 group addresses as station addresses just because the link layer doesn't define multicast functionality is wrong from my point of view.
When this address is invalid and the MAC layer doesn't use this bit. Then we need to care that we drop all frames with the source address with this bit. I also don't see that any transceiver with address filtering enabled will drop this frame (okay they also don't filter 0x00..00 and 0xff...ff) frames.
I am currently really unsure and looking in well-known IoT OS, if they look on this bit. But I didn't saw anything. Only that the most using the same like eth_random_addr address and fill with ff fe bit pattern. Maybe to operate with some virtual linux networking ethernet interfaces which are connected over slip and tun/tap and such things...
- Alex
[0] http://lxr.free-electrons.com/source/net/ieee802154/6lowpan/tx.c#L219
[1] https://tools.ietf.org/html/rfc4944#section-6
Alexander Aring
maintainerGrml, I think I am getting too much confuses right now.
Quoted 85 lines · Alexander Aring
Quoted 51 lines · Lennert Buytenhek
Quoted 44 lines · Alexander Aring
Quoted 11 lines
Currently,
ieee802154_random_extended_addr()has a 50% chance of generating a group (multicast) address, while this function is used for generating station addresses (which can't be group addresses) for interfaces that don't have a hardware-provided address.Also, in case
get_random_bytes()generates the EUI-64 address 00:00:00:00:00:00:00:00 (extremely unlikely), which is an invalid address,ieee802154_random_extended_addr()reacts by changing it to 01:00:00:00:00:00:00:00, which is an invalid station address as well, as it is a group address.Quoted 4 lines
This patch changes the address generation procedure to grab eight random bytes, treat that as an EUI-64, and then clear the Group address bit and set the Locally Administered bit, which is in line with how
eth_random_addr()generates random EUI-48s.This is one thing which I asked myself already. If the group address comming from EUI-64 standard or not. What I can say is that the 802.15.4 MAC layer doesn't care about this bit and we don't have _any_ multicast functionality.
What you try to do is to map ethernet MAC functionality to 802.15.4 MAC. The 802.15.4 have no special bits inside the EUI64 which indicates something. Our multicast functionality is done by a broadcast (done by short address, which is currently indicate by a 0xff..ff extended addr, because IPv6 can't deal at the moment deal with two types of mac address types.)
What I always find is this document [0]. Which describes that the 0x00..00 and 0xff...ff are invalid. (And a node should really not use 0xff..ff since we have the workaround with IPv6 for broadcast).
If we would have such bit, then we also need to implement [1], which generates the multicast address according the IPv6 address. At the moment we get the
dev->broadcastaddress which is correct, because we don't have multicast functionality.I don't ack this patch, because I don't see at the moment that this is wrong. Maybe I don't get it. If IPv6 checks on this bit and indicates a multicast on L2 _then_ we should change it, but I don't think that IPv6 do that.
Quoted 9 lines
Your [0] document states that EUI-64 addresses start with an OUI, and the structure of the OUI is documented in this document:
https://standards.ieee.org/develop/regauth/tut/eui.pdf
Page 4 of this document shows that every OUI(/CID) contains the Universal/Local and Individual/Group address bits, and this is true no matter whether this OUI is part of an EUI-48 or an EUI-64.
yes this makes sense and one argument to change it to your behaviour.
Quoted 10 lines
Also compare your [0] with this document:
http://standards.ieee.org/develop/regauth/tut/eui48.pdf
And note how neither the EUI-48 nor the EUI-64 PDFs talk about group addresses -- this is because an EUI-{48,64} contains an OUI, and the OUI contains the scope/group bits, and so the documents explaining the EUI-{48,64} format are not the right place to discuss those bits, although they exist both in EUI-48 and in EUI-64 addresses.
Quoted 4 lines
Just the fact that 802.15.4 spec doesn't talk about multicast doesn't suddenly redefine the EUI-64 group bit as just another unicast address bit, in my humble opinion, but this is what Linux is currently doing.
The 802.15.4 spec doesn't also say any words about that the "extended address" is an EUI-64 address. 6LoWPAN RFC says it should handled like a EUI-64 [1]. General question is "Is the extended-address in 802.15.4 really meaning an EUI-64 address?". Sorry for this newbie question, but this is what I am asking myself now.
Quoted 6 lines
What I see is that the extended-addr is described as "The 64-bit (IEEE) address assigned to the device." Which says to me it's an EUI-64, or?
But then this means 0x00..00 and 0xff..ff are also valid, but IPv6 can't deal with the 0x00..00.
forget this sentence. I mean this is true when extended_addr != EUI-64 but I don't think that's true.
Quoted 17 lines
Quoted 6 lines
From a hardware point of view, multicast packets should never be ACKed, so there is no need for the hardware to be aware of the active multicast addresses on this interface per se. (We could theoretically pass the multicast address list for the interface to the hardware to allow doing frame filtering in hardware, but this does not affect operational correctness.)
So then we should also add a check of this bit at [0]? Then set the ackreq bit to 0 if the bit is set?
Quoted 6 lines
Whether we should be using EUI-64 group addresses on the "wire" for 802.15.4 for multicast (IPv6) traffic is another question, but using EUI-64 group addresses as station addresses just because the link layer doesn't define multicast functionality is wrong from my point of view.
Quoted 6 lines
When this address is invalid and the MAC layer doesn't use this bit. Then we need to care that we drop all frames with the source address with this bit. I also don't see that any transceiver with address filtering enabled will drop this frame (okay they also don't filter 0x00..00 and 0xff...ff) frames.
I mean here how we should react globally about source address which have this bit set? When it's source address then we should drop it and destination address? I don't know. :-)
- Alex
Quoted 1 line · Alexander Aring
Grml, I think I am getting too much confuses right now.
:-)
Quoted 21 lines
Quoted 21 lines
Quoted 10 lines
Also compare your [0] with this document:
http://standards.ieee.org/develop/regauth/tut/eui48.pdf
And note how neither the EUI-48 nor the EUI-64 PDFs talk about group addresses -- this is because an EUI-{48,64} contains an OUI, and the OUI contains the scope/group bits, and so the documents explaining the EUI-{48,64} format are not the right place to discuss those bits, although they exist both in EUI-48 and in EUI-64 addresses.
Quoted 4 lines
Just the fact that 802.15.4 spec doesn't talk about multicast doesn't suddenly redefine the EUI-64 group bit as just another unicast address bit, in my humble opinion, but this is what Linux is currently doing.
The 802.15.4 spec doesn't also say any words about that the "extended address" is an EUI-64 address. 6LoWPAN RFC says it should handled like a EUI-64 [1]. General question is "Is the extended-address in 802.15.4 really meaning an EUI-64 address?". Sorry for this newbie question, but this is what I am asking myself now.
Quoted 8 lines
Quoted 5 lines
What I see is that the extended-addr is described as "The 64-bit (IEEE) address assigned to the device." Which says to me it's an EUI-64, or?
But then this means 0x00..00 and 0xff..ff are also valid, but IPv6 can't deal with the 0x00..00.
forget this sentence. I mean this is true when
extended_addr!= EUI-64 but I don't think that's true.
Right, OK, makes sense.
Quoted 22 lines
Quoted 16 lines
Quoted 6 lines
From a hardware point of view, multicast packets should never be ACKed, so there is no need for the hardware to be aware of the active multicast addresses on this interface per se. (We could theoretically pass the multicast address list for the interface to the hardware to allow doing frame filtering in hardware, but this does not affect operational correctness.)
So then we should also add a check of this bit at [0]? Then set the ackreq bit to 0 if the bit is set?
Quoted 5 lines
Whether we should be using EUI-64 group addresses on the "wire" for 802.15.4 for multicast (IPv6) traffic is another question, but using EUI-64 group addresses as station addresses just because the link layer doesn't define multicast functionality is wrong from my point of view.
Quoted 5 lines
When this address is invalid and the MAC layer doesn't use this bit. Then we need to care that we drop all frames with the source address with this bit. I also don't see that any transceiver with address filtering enabled will drop this frame (okay they also don't filter 0x00..00 and 0xff...ff) frames.
Quoted 3 lines
I mean here how we should react globally about source address which have this bit set? When it's source address then we should drop it and destination address? I don't know. :-)
I don't think we can get away with changing our behavior to start being strict about the source address group bit. :(
Quoted 14 lines · Alexander Aring
Quoted 10 lines
Also compare your [0] with this document:
http://standards.ieee.org/develop/regauth/tut/eui48.pdf
And note how neither the EUI-48 nor the EUI-64 PDFs talk about group addresses -- this is because an EUI-{48,64} contains an OUI, and the OUI contains the scope/group bits, and so the documents explaining the EUI-{48,64} format are not the right place to discuss those bits, although they exist both in EUI-48 and in EUI-64 addresses.
Quoted 3 lines
Just the fact that 802.15.4 spec doesn't talk about multicast doesn't suddenly redefine the EUI-64 group bit as just another unicast address bit, in my humble opinion, but this is what Linux is currently doing.
Quoted 8 lines
The 802.15.4 spec doesn't also say any words about that the "extended address" is an EUI-64 address. 6LoWPAN RFC says it should handled like a EUI-64 [1]. General question is "Is the extended-address in 802.15.4 really meaning an EUI-64 address?". Sorry for this newbie question, but this is what I am asking myself now.
What I see is that the extended-addr is described as "The 64-bit (IEEE) address assigned to the device." Which says to me it's an EUI-64, or?
You are right that there are no occurences of the "OUI" or "EUI" strings in the 802.15.4 spec (good observation -- I hadn't noticed this before!). I'm basing my assumption that 802.15.4 64 bit addresses are EUI-64s on this remark in 802.15.4-2011 section 5.2:
A device’s extended address shall be a 64-bit universal address, as defined by the IEEE Registration Authority. [5]
Where footnote 5 is:
[5] Interested applicants should contact the IEEE Registration Authority, http://standards.ieee.org/develop/regauth/.
On this web page, the only listed IEEE registries that seem relevant ot me are the OUI registries (MA-L, MA-M, MA-S) -- none of the other registries look like they could be the ones referenced by this remark in the 802.15.4 spec. This to me suggests that the 64 bit address is an EUI-64, even if the literal term "EUI-64" isn't used anywhere.
And, as you remarked as well, there are several other references online that suggest that 802.15.4 addresses are EUI-64s, for example this TI FAQ page:
https://e2e.ti.com/support/wireless_connectivity/w/design_notes/acquiring-ieee-address-range-802-15-4-mac-z-stack-zigbee-cc2420-cc2430-cc2431-cc2530-cc2531
Which has:
Q: FAQ: Acquiring IEEE address range (802.15.4 MAC, Z-stack, ZigBee, CC2420, CC2430, CC2431, CC2530, CC2531)
The IEEE 64 bit address is known at IEEE as the EUI-64(tm) which is a concatenation of the 24-bit OUI (Company ID) value assigned by the IEEE Registration Authority and a 40-bit extension identifier assigned by the organization with that OUI assignment.
A one time fee of $1,650.00(US) is required. The addresses used for 802.15.4 has the same format and ranges as Ethernet MAC addresses.
Quoted 2 lines
But then this means 0x00..00 and 0xff..ff are also valid, but IPv6 can't deal with the 0x00..00.
0xff..ff wouldn't be valid as a station address as it is a group address, and https://standards.ieee.org/develop/regauth/tut/eui64.pdf
also contains this remark:
The all-zeros and all-ones EUI-64 values, 00-00-00-00-00-00-00-00_hex and FF-FF-FF-FF-FF-FF-FF-FF_hex, are owned by the IEEE Registration Authority and will never be assigned, and are invalid for use as identifiers.
Quoted 9 lines
Quoted 6 lines
From a hardware point of view, multicast packets should never be ACKed, so there is no need for the hardware to be aware of the active multicast addresses on this interface per se. (We could theoretically pass the multicast address list for the interface to the hardware to allow doing frame filtering in hardware, but this does not affect operational correctness.)
So then we should also add a check of this bit at [0]? Then set the ackreq bit to 0 if the bit is set?
I would think so, but also, all v6 multicast addresses should be mapped to the broadcast short address (when not using mesh mode), according to RFC4944:
This document assumes that a PAN maps to a specific IPv6 link. This complies with the recommendation that shared networks support link- layer subnet [RFC3819] broadcast. Strictly speaking, it is multicast not broadcast that exists in IPv6. However, multicast is not supported natively in IEEE 802.15.4. Hence, IPv6 level multicast packets MUST be carried as link-layer broadcast frames in IEEE 802.15.4 networks. This MUST be done such that the broadcast frames are only heeded by devices within the specific PAN of the link in question. As per Section 7.5.6.2 in [ieee802.15.4], this is accomplished as follows:
1. A destination PAN identifier is included in the frame, and it MUST match the PAN ID of the link in question.
2. A short destination address is included in the frame, and it MUST match the broadcast address (0xffff).
So I thiiiink (but I haven't had my morning caffeine yet) that the lowpan_is_addr_broadcast() check in lowpan_header() should be matching on all multicast destination addresses instead.
Quoted 11 lines
Quoted 5 lines
Whether we should be using EUI-64 group addresses on the "wire" for 802.15.4 for multicast (IPv6) traffic is another question, but using EUI-64 group addresses as station addresses just because the link layer doesn't define multicast functionality is wrong from my point of view.
When this address is invalid and the MAC layer doesn't use this bit. Then we need to care that we drop all frames with the source address with this bit. I also don't see that any transceiver with address filtering enabled will drop this frame (okay they also don't filter 0x00..00 and 0xff...ff) frames.
For 802.3 ("plain" ethernet), we drop frames that have the group address bit set in the frame source address, and in theory we should probably be doing the same for 802.15.4, but in practise, I don't think we can justify making this change now, as we already have an installed base that happily uses group addresses as station addresses, and making this change would break compatibility with those devices, with no obvious advantage other than spec compliance.
If some future 802.15.4 stack change makes it necessary to start dropping received frames with the group address bit set in the source address, then I guess we can consider it, but at this point I just don't see enough justification to intentionally break communication with older Linux boxes with 50% probability (which is the probability of them generating a group address as station address).
Quoted 5 lines
I am currently really unsure and looking in well-known IoT OS, if they look on this bit. But I didn't saw anything. Only that the most using the same like
eth_random_addraddress and fill with ff fe bit pattern. Maybe to operate with some virtual linux networking ethernet interfaces which are connected over slip and tun/tap and such things...
ff fe bit pattern?
Hello.
Quoted 9 lines · Lennert Buytenhek
Quoted 5 lines · Alexander Aring
I am currently really unsure and looking in well-known IoT OS, if they look on this bit. But I didn't saw anything. Only that the most using the same like
eth_random_addraddress and fill with ff fe bit pattern. Maybe to operate with some virtual linux networking ethernet interfaces which are connected over slip and tun/tap and such things...ff fe bit pattern?
What they do is mapping a EUI-48 to a EUI-64 following the guidelines from:
https://standards.ieee.org/develop/regauth/tut/eui48.pdf page 4
The two missing octets are filled in with either FF FE or FF FF. The padding happens after the first three bytes with the OUI and the rest of the EUI-48.
regards
Stefan Schmidt
Quoted 1 line · Stefan Schmidt
Hello.
Hi!
Quoted 7 lines
Quoted 6 lines
Quoted 5 lines
I am currently really unsure and looking in well-known IoT OS, if they look on this bit. But I didn't saw anything. Only that the most using the same like
eth_random_addraddress and fill with ff fe bit pattern. Maybe to operate with some virtual linux networking ethernet interfaces which are connected over slip and tun/tap and such things...ff fe bit pattern?
Quoted 8 lines
What they do is mapping a EUI-48 to a EUI-64 following the guidelines from:
https://standards.ieee.org/develop/regauth/tut/eui48.pdf page 4
The two missing octets are filled in with either FF FE or FF FF. The padding happens after the first three bytes with the OUI and the rest of the EUI-48.
Ah yes, I remember that, I just couldn't figure
out what the 'ff fe bit pattern' remark was
referring to -- thanks for clarifying. :)
Quoted 11 lines · On Thu, 28 May 2015 15:38:32 +0300 Lennert Buytenhek <[email protected]>…
Currently,
ieee802154_random_extended_addr()has a 50% chance of generating a group (multicast) address, while this function is used for generating station addresses (which can't be group addresses) for interfaces that don't have a hardware-provided address.Also, in case
get_random_bytes()generates the EUI-64 address 00:00:00:00:00:00:00:00 (extremely unlikely), which is an invalid address,ieee802154_random_extended_addr()reacts by changing it to 01:00:00:00:00:00:00:00, which is an invalid station address as well, as it is a group address.
Quoted 4 lines
This patch changes the address generation procedure to grab eight random bytes, treat that as an EUI-64, and then clear the Group address bit and set the Locally Administered bit, which is in line with how
eth_random_addr()generates random EUI-48s.
Looks good to me. Even if this ends up being uneccessarily strict, we'll always have a huge pool of addresses we may generate.
Note: the standard only says that the address shall be a 64 bit universal address (not excluding multicast), but not generating multicast EUIs seems like a good idea anyway.
Quoted 24 lines
Signed-off-by Lennert Buytenhek <[email protected]>--- include/linux/ieee802154.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)include/linux/ieee802154.h +3
-3@@ -244,9 +244,9 @@ static inline void ieee802154_random_extended_addr(__le64 *addr) {get_random_bytes (addr,IEEE802154_EXTENDED_ADDR_LEN ); -/* toggle some bit if we hit an invalid extended addr */ -if (!ieee802154_is_valid_extended_addr (*addr)) - ((u8 *)addr)[IEEE802154_EXTENDED_ADDR_LEN -1 ] ^=0x01 ; +/* clear the group bit, and set the locally administered bit */ + ((u8 *)addr)[IEEE802154_EXTENDED_ADDR_LEN -1 ] &= ~0x01 ; + ((u8 *)addr)[IEEE802154_EXTENDED_ADDR_LEN -1 ] |=0x02 ; }#endif /*
LINUX_IEEE802154_H*/
Hi,
Quoted 19 lines · Phoebe Buckheister
Quoted 11 lines · On Thu, 28 May 2015 15:38:32 +0300 Lennert Buytenhek <[email protected]>…
Currently,
ieee802154_random_extended_addr()has a 50% chance of generating a group (multicast) address, while this function is used for generating station addresses (which can't be group addresses) for interfaces that don't have a hardware-provided address.Also, in case
get_random_bytes()generates the EUI-64 address 00:00:00:00:00:00:00:00 (extremely unlikely), which is an invalid address,ieee802154_random_extended_addr()reacts by changing it to 01:00:00:00:00:00:00:00, which is an invalid station address as well, as it is a group address.Quoted 4 lines
This patch changes the address generation procedure to grab eight random bytes, treat that as an EUI-64, and then clear the Group address bit and set the Locally Administered bit, which is in line with how
eth_random_addr()generates random EUI-48s.
Quoted 6 lines
Looks good to me. Even if this ends up being uneccessarily strict, we'll always have a huge pool of addresses we may generate.
Note: the standard only says that the address shall be a 64 bit universal address (not excluding multicast), but not generating multicast EUIs seems like a good idea anyway.
thanks Phoebe for clarify this. You both convince me to change it.
Thanks that we clarify this.
Quoted 1 line
Quoted 1 line
Signed-off-by Lennert Buytenhek <[email protected]>
Hi Lennert,
Quoted 16 lines
Currently,
ieee802154_random_extended_addr()has a 50% chance of generating a group (multicast) address, while this function is used for generating station addresses (which can't be group addresses) for interfaces that don't have a hardware-provided address.Also, in case
get_random_bytes()generates the EUI-64 address 00:00:00:00:00:00:00:00 (extremely unlikely), which is an invalid address,ieee802154_random_extended_addr()reacts by changing it to 01:00:00:00:00:00:00:00, which is an invalid station address as well, as it is a group address.This patch changes the address generation procedure to grab eight random bytes, treat that as an EUI-64, and then clear the Group address bit and set the Locally Administered bit, which is in line with how
eth_random_addr()generates random EUI-48s.
Quoted 4 lines
Signed-off-by Lennert Buytenhek <[email protected]>---
include/linux/ieee802154.h| 6 +++---1 file changed, 3 insertions(+), 3 deletions(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel