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
