Re: [PATCH,RFC bluetooth-next 1/2] ieee802154: Fix generation of random EUI-64 addresses.

[Alexander Aring <alex.aring@gmail.com>]

On Thu, May 28, 2015 at 04:39:48PM +0300, Lennert Buytenhek wrote:
> On Thu, May 28, 2015 at 03:17:15PM +0200, Alexander Aring wrote:
> 
> > > 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.
> > 
> > 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
> 
> 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.

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

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.

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

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