Suggested Topic: Managing locally-administered Ethernet addresses in a thoughtful way

• Background on Ethernet MAC addresses
  
• As you know, all IEEE 802 networks (including Ethernet) use 48-bit host addresses. These addresses are described as a sequence of 6 "octets" (aka "bytes") or 12 hexadecimal characters and their transmission order is defined to be left-first at the octet level and least-significant-first at the bit level within each octet. (See the wikipedia page and section 9.5 of the IEEE 802 standard.) Furthermore:
• the least-significant bit of the first octet (i.e., "first on the wire") is 0 for unicast, 1 for multicast
• the second-least significant bit of the first octet (i.e., "second on the wire") is 0 for universal (globally unique and administered by IEEE), 1 for local (do what you like, nobody can stop you)
  
• Even though half the available pool of MAC addresses is locally administered, everybody has generally ignored them for decades because the (small) risk of an address conflict far outweighed the (much smaller) cost of obtaining some universal addresses from the IEEE.
• Recently, however, there has been a new interest in local MAC addresses for several reasons:
• universal MAC addresses can only be assigned to physical devices, so it is illegal to assign them to individual pieces of data, or -- more seriously -- virtual machines in a data center.
• After 35 years, privacy advocates have suddenly realized that a universal MAC address can be used to track their movements and/or Internet activity -- particularly on public wireless networks where anybody can be listening -- and are advocating randomly-generated MAC addresses.
  
• As the size of bridged networks in large data centers increases, it becomes difficult and expensive to manage a completely flat MAC address space, so some researchers are exploring structured assignment of MAC addresses according to location.
  
• Networks that want locally-administered MAC addresses to create their own structured environment could use a mechanism for layer-2 network address translation, to "cleanse" their networks of addresses that don't fit the intended structure.
  

1. Modify DHCP, for dynamic allocation of IP addresses, to add the option to give out a MAC address at the same time. Note that this change is complicated by the fact that DHCP currently uses the MAC address as a unique ID for identifying the current borrower of an IP address, so you will need to invent some other mechanism(s).
   
• This protocol could be applied to either the "virtual machine" problem or the "WiFi privacy" problem
• In the "virtual machine" problem, each VM instance could be initialized to use the same starting value, if the hypervisor handled the DHCP-like address assignment request internally. This is because the hypervisor knows the current hypervisor slot occupied by each active VM and can use it as its unique ID).
• In the "WiFi privacy" problem, you can't identify the borrower based on its location since everyone is "one hop away" from the base station. Perhaps a TCP-like clock-based algorithm could be used as a node's temporary ID, but you would need to check for duplicate values and find a randomized method for breaking such "ties". (I suggest you look to the binary exponential backoff for help.  For example, assume the clock-based algorithm produces integer values, and if the server receives more than one request with the same ID before it has completed the assignment to one individual, it tells all requestors to randomly extend the time ID by adding some fractional bits. On the other hand, if the server receives a new request with a time ID that is already"in use" by someone else, the server rejects the request and tells the new requestor to start again with a new timeID.)
  
• Don't forget you need mechanisms by which the server can check whether the borrower is still using its assigned MAC address, and for the borrow to "return" its MAC address if it decides to leave the network gracefully.

2. Design a layer-2 MAC Address Translation (MAT) capability that can be added to layer-2 bridges to manage locally-assigned MAC addresses. In this case, assume that each bridge in a layer-2 network has its own block of locally-assigned MAC addresses, and is responsible for making sure that the only locally-assigned MAC addresses that get sent throught its "uplink ports" (i.e., connecting to other cooperating bridges, not end nodes or non-cooperating bridges) come from its own address block.
   
• The bridges could learn which ones support this MAT capability, and request their own local addres block through an extended version of the Spanning Tree protocol.
• Once everything is established, their forwarding tables would include a "personal name", "public name" and "destination port" for each host entry.
• Note that ARP needs to be treated specially in such a network because a copy of the destination's MAC address is included in the payload field of an ARP response packet.