ctys-private-MAC-Addresses

January, 2011

NAME

ctys-private-MAC-Addresses - Receipt for assignment of private MAC Addresses

General

This is just an short extract of repetition for understanding WHY a VMs MAC-address should begin with either '2', or '6', or 'A', or 'E' - shortly [26AE]. The knowledge of this is an mandatory and essential building block, when assigning addresses to NICs - a.k.a. VNICs - of VMs for participation of the VM on LAN communications. So will be given thoroughly here.

First of all - this item is described excellently in the book of Charles E. Spurgeon [etherDefGuide] at pg. 42. Application hints with general visual VM-Networking explanation and a short sum-up for application of MAC-Addresses on VMs are available at the Xen-Wiki [xenWiki] . The standards are available at ieee.org [ http://www.ieee.org ] .

A short Receipt

The basis for this numbering are the so called DIX and IEEE 802.3 standards. The following items give a short extract:

Multicast-bit - by DIX and IEEE 802.3
The Ethernet frames use the first bit of destination address for distinction between:
- an explicitly addressed single target - a.k.a. physical or unicast address.
- a group of recipients with an logical address - a.k.a. multicast address
- The syntax is given by most significant bit in Network Order:
```
    0: unicast
    1: multicast
```
  Which is 'X' for frames bit-stream:
```
  Xnnn mmmm rrrr ssss ....
```

Locally and Globally Administered Addresses - IEEE 802.3
This is defined for IEEE 802.3 only. This bit defines the namespace of (to be cared of!) unambiguity for the given address due to it's administrators area of responsibility.
- globally administered addresses
  To be used by public - so globally coordinated - access, which has to prevent anyone from buying two NICs with the same MAC-Address.
- locally administered addresses
  Could be used according to policies of locally responsible administrators. This is particularly required for management of VMs, when these should be used in bridged mode, which is a transparently complete host network access as for any physical host.
- The syntax is given by second significant bit in Network Order:
```
  0: globally administered
  1: locally administered 
```
  Which is 'Y' for frames bit-stream:
```
  nYnn mmmm rrrr ssss ....
```

Distinction of Network-Order and Representation-Order
The given control bits from the network standards are related to networking, thus address positions in network streams as bit-representation. But the MAC-Address - 48bit - are written as 6 Octets of hexadecimal nibbles seperated by colons - for human readability. The difference of both for the actual "bit-order" arises from the "different logical handling units" for the actual set of bits. Whereas the Network-Order assumes a bit as unit, the Representation Order assumes nibbles grouped to octets as handling units. So the definition of both units are:
- Network-Order:
  bit as unit, and a constant bit-stream indexed incrementally beginning with the first bit
- Representation-Order:
  nibble as unit, grouped to octets as least-significant nibble - containing the least significant bits of a bit stream - first
- Thus the resulting mapping is given by:
  - Network-Order:
```
    nnnn mmmm rrrr ssss ....
    N    M    R    S   ....
```
  - Representation-Order, where additionally the bit-order within the nibble is swapped by definition:
```
  MN:SR:...
```
    with N from n0-n1-n2-n3 to N3-N2-N1-N0.
```
  Network:         0001 = 0x1
  Representation:  1000 = 0xF
```
  - Assuming that for a VM only addresses of following types should be used or to say 'are valid':
```
    
  unicast + locally administered
    
  This results to :
    
    01nn mmmm rrrr ssss ...
   
  ...which is represented as:
    
    M{nn10}:SR:...
   
  ...so has even values only beginning with 2 -  N=2+n*4:   
    
    {nn10}={2,6,10,14}={0x2,0x6,0xA,0xE}=[26AE]
    
  ...finally referring to the guide on "XenNetworking-Wiki":
    
    "aA:..." is a valid address, whereas "aB:...." is not.
  
```
    Mentioning this for completeness - any value of a MAC-Address, where the second nibble of the leftmost octet has one of the values [26AE], is valid.
    
    So, ...yes, no rule without exception. When dealing with commercial products, free or not, any addressing-pattern could be predefined for manual and generic MAC-Address assignment within a valid "private" range of the products supplier. This is the case when the first 3 octets of the MAC-Address are defined to be fixed - which is e.g. the suppliers globally assigned prefix - whereas any numbering range could be defined within the following 3 octets.
    
    The given convention should be recognized, because it might be checked by any undisclosed hardcoded piece of code. For details refer to the specific manuals when required. "ctys" supports the display of MAC-Addresses as it does UUIDs by action ENUMERATE. This could be used to check uniqueness and might be supported as a ready-to-use MACRO.

AUTHOR

Arno-Can Uestuensoez	<https://arnocan.wordpress.com/>
	<https://unifiedsessionsmanager.sourceforge.io/>
	<https://github.com/unifiedsessionsmanager>

COPYRIGHT

For BASE package following licenses apply,

for software see GPL3 for license conditions,
for documents see GFDL-1.3 with invariant sections for license conditions,

This document is part of the DOC package,

for documents and contents from DOC package see
'Creative-Common-Licence-3.0 - Attrib: Non-Commercial, Non-Deriv'

with optional extensions for license conditions.

For additional information refer to enclosed Releasenotes and License files.