Re: Random or Global MACaddr

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 11/05/2014 03:19 AM, Peter Robinson wrote:
On Wed, Nov 5, 2014 at 2:55 AM, Robert Moskowitz <rgm@xxxxxxxxxxxxxxx> wrote:
I am in an IEEE 802 MACaddr debate right now, where there is a PAR proposal
that will segment the local scope address space.  Quite a mess and I am very
depressed....

I use Cubieboards that do not have a registered CID to provide a global
MACaddr, and instead leaves it up to the OS to workout a local MACaddr.

Is this the common case for ARMv7 (and v8) boards or the exception?

What does the beagle boards do?  wandboards?  Oh, now Raspberry PI has
ethernet and what does it do?
It's quite common to not assign a MAC. After all it needs to be stored
somewhere. In a x86 device where the NIC is onboard the motherboard
this is generally in the main PC BIOS and that assigns it on boot. In
a PCI(e) NIC it's generally on a little eeprom on the board but with
the ARM dev boards where the whole device is $35 and they don't even
ship flash for a bootloader to reduce cost the added expense, even of
a couple of cents, isn't in the manufacturers eyes isn't worth the cut
in their profit. In the embedded/devboard/IoT space I would tend to
say it's more the norm than the exception.

But I aways wonder that there is the NAND where they COULD put such stuff, but don't.

Many IoT are 802.15.4 which is the 64bit MAC. Though I would like to see what NEST does, thinking about it.



As more expensive ARM devices appear such as servers and laptops I
suspect that won't be the case for those devices as they're more
consumer aimed and the added support costs alone of random MACs would
justify a bit of extra costs on a chromebook or similar.

But as we work out how to provide privacy for MACaddrs, many laptops/tablets may opt to go with only random addresses and not pay for a CID. IEEE is really worried about this.

I would have expected an organisation such as the IEEE 802 ethernet
committee would already know this having done appropriate levels of
research with the companies paying them for MACs, or in the case of
the ARM space, not.  It seems they really are out of touch :-)

RAC politics is interesting. Their charter allows them to meet in private and only announce things afterwards. Past activities of vendors jumping on ethertypes before decisions were finalized in part warrant this behaviour, but the rest of us have often been caught in a Catch-22 is saying something is policy and the RAC then announcing that it isn't because the policy is private so how could we know? Grrrr.

Part of the challenge is the VM space and how they want to carve off part of the local space for only their use. This would cause others to change how they select smaller random assignments with increase chance of collision. But then I am proposing a MACaddr management protocol where a controller (say the DHCP server) could require cryptographic proof for using a local MACaddr and resolve conflicts by forcing some to select a different MACaddr and try again. See my HIP protocol in the IETF and how I work with HITs in the IPv6 space to get an idea how I could do this in 802.1 for MACaddr use. But with anything in the IEEE it will take us minimum of a year to agree on anything new.

When I showed my Cubieboard last night there was considerable interest in getting that the game has changed. I really don't believe that these EEs really understand the ARMment race.


_______________________________________________
arm mailing list
arm@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/arm





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux ARM (Vger)]     [Linux ARM]     [ARM Kernel]     [Fedora User Discussion]     [Older Fedora Users Discussion]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Maintainers]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Coolkey]     [Yum Users]     [Tux]     [Yosemite News]     [Linux Apps]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]

Powered by Linux