Adding randomized MAC address option on ifconfig.

[araujo]

Summary

Add a "random" option that combined with "ether" can generate a random MAC address for a Ethernet interface.

Also update ifconfig(8) manpage and fix few typos.

PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211984
Original patch: https://gist.github.com/t6

Test Plan

ifconfig tap0 create
ifconfig tap0 ether 01:01:01:01:01:01
ifconfig tap0
ifconfig tap0 ether random
ifconfig tap0

[araujo]

Seems it might have some restrictions that need to deal with when generate a random MAC ADDRESS, such like:

https://tools.ietf.org/html/rfc5342#section-2.1.1
https://tools.ietf.org/html/rfc5342#section-2.2.2
https://tools.ietf.org/html/rfc5342#section-2.3.1
https://tools.ietf.org/html/rfc5342#section-2.3.2

I might have overlooked some other.

[gnn]

I am somewhat confused. I don't see anything about random addresses in the RFC mentioned in the followup.

[pi]

The patch adds a option random, which creates random MAC addresses for an ethernet interface. The problem: What happens if a random MAC is selected which has some meaning for multicast etc ? To avoid that, the option needs to
make sure it does not generate one of those 'special' MACs.

This is why araujo is researching which MAC ranges are reserved for special use cases.

[gnn]

I guess my other fear is that the address might overlap an existing allocation. What is the use case for random MACs?

[pi]

Yes, duplicate MACs might happen.

Privacy, or 'secrecy' or 'OpSec' is the use-case. Now, what was my personal domainname again 8-} ?

[pi]

For the 'duplicate-MAC' case, that issue should be mentioned in the man-page.

But the feature itself is valid, given the appreciation of values.

[cem]

In D7615#158300, @gnn wrote:

I guess my other fear is that the address might overlap an existing allocation. What is the use case for random MACs?

Duplicates are fairly unlikely, right? We have 48 bits; so the odds of a collision is something like 2^-24.

[• lidl]

sbin/ifconfig/af_link.c

100

I think this should really be clearing the lowest bit of the first octet to clean the multicast bit, and then setting on the second lowest bit of the first octet, to indicate that this is a locally administered MAC address.

[jhb]

I think the possibility of duplicates should just be documented. I'd lean towards not having the code automatically retry if the randomly generated MAC collides with an existing interface on the machine, but others might favor the automatic retry. OTOH, it's actually ok if different interfaces on the same machine have the same MAC so long as they aren't on the same subnet. (Recall that Sun used to ship sparc boxes that used the same MAC on both ports of dual-port NICs on the assumption that you would only use two ports if you were bridging two different LANs).

[wblock]

sbin/ifconfig/ifconfig.8

148

Needs a comma for the pause after "address", but we can rearrange to avoid that pause:

Use the
.Pq Dq random
keyword to set a randomly generated MAC address.

And then the warnings should be mentioned:

The odds of a random MAC address suffering an inelastic collision with an existing MAC address are low.
Do not use with roller skates.
Possible side effects include giddiness, nausea, and thinking that XML is a good idea.

[araujo]

Address the update on ifconfig(8) about the possibility to have
duplicate mac address.

[rpokala]

sbin/ifconfig/ifconfig.8

151

s/but//

[araujo]

Remove s/but// suggested by rpokala@.

[wblock]

sbin/ifconfig/ifconfig.8

152

A randomly-generated MAC address might be the same as
one already in use in the network.  Such duplications are
extremely unlikely.

[araujo]

Address @wblock suggestion.

[wblock]

sbin/ifconfig/ifconfig.8

152

Please start new sentences on new lines.

Also, typo: s/ducplications/duplications/

[araujo]

Fix typo and start sentence in new line.
Spotted by @wblock.

[araujo]

Committed already!

Thanks!