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

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

Grml, I think I am getting too much confuses right now.

On Thu, May 28, 2015 at 04:42:49PM +0200, Alexander Aring wrote:
> 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.
> 

forget this sentence. I mean this is true when extended_addr != EUI-64
but I don't think that's true.

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