[Madinas] towards a taxonomy of RCM

[Michael Richardson <[e-mail]>]

I wanted access to the github/XML for the documents so that I could
intelligently propose text.  I'm happy to help put the documents into git in
a useful fashion (dumping foo-01.xml, foo-02.xml is not useful). 
Please just unicast me.  I've gone head with framework, at:
    https://github.com/mcr/madinas-framework

At the IETF112 meeting (or maybe it was earlier), many felt that instead of
trying to keep track of what OS/version/product was doing what in the
document (or even in a wiki), that it was more productive to just create a
taxonomy of behaviours. 

I thought that this should go into the framework document, but now I'm not so
clear at all.  I'm just gonna post my text here.   TLAs are subject to usual
bike shedding.

If you prefer you can send pull requests against:
  https://github.com/mcr/madinas-framework/blob/main/mac-address-policies.md

but it might be that we need to decide if this goes into "framework" or the
other document.

----

# MAC address selection policies

This section documents five different policies for MAC address selection.

XXX-The names are subject to change.
The "M" in MAC is included in the acronym, but not the "A" from address.
This allows one to talk about a PVOM Address, or PNGM Address.

The names are all in the form for per-period-of-time-selection.

## Per-Vendor OUI MAC address (PVOM)

This form of MAC address selection is the historical default.
The vendor obtains an Organizationally Unique Identifier (OUI) from the IEEE.
This has been a 24-bit prefix (including two upper bits which are set specifically) that is assigned to the vendor.
The vendor generates a unique 24-bit value for the lower 24-bits, forming the 48-bit MAC address.
It has not been unusual for the 24-bit value to be taken as an incrementing counter, assigned at the factory, and burnt into non-volatile storage.

Note that 802.15.4 use 64-bit MAC addresses, and the IEEE assigns 32-bit prefixes.
The IEEE has indicated that there may be a future Ethernet specification using 64-bit MAC addresses.

## Per-Device Generated MAC address (PDGM)

This form of MAC address is randomly generated by the device, usually upon first boot.
The resulting MAC address is stored in non-volatile storage and is used for the rest of the device lifetime.

## Per-Boot Generated MAC address (PBGM)

This form of MAC address is randomly generated by the device, each time the device is booted.
The resulting MAC address is *not* stored in non-volatile storage.
It does not persist across power cycles.
This case may sometimes be a PDGM where the non-volatile storage is no longer functional
(or has failed).

## Per-Network Generated MAC adress (PNGM)

This form of MAC address is generated each time a new network connection is created.
This is typically used with WiFi (802.11) networks where the network is identified by an SSID Name.
The generated address is stored on non-volatile storage, indexed by the SSID.
Each time the device returns to a network with the same SSID, the device uses the saved MAC address.

It is possible to use PNGM for wired ethernet connections through some passive observation of network traffic, such as STP, LLDP, DHCP or Router Advertisements to determine which network has been attached.

## Per-Session Generated MAC address (PSGM)

This form of MAC address is generated each time a new network connection is created.
Like PNGM, it is used primarily with WiFi (802.11).
The generated address is not stored on non-volatile storage, nor in any in-device database.
Should the device disconnect from that SSID and then reconnect, a new MAC address will be generated.

As there are often small interruptions in hand-over between access points, this MAC address usually needs to be kept for short times.

## Per-Period Generated MAC address (PPGM)

This form of MAC address is generated periodically.
Typical numbers are around every twelve hours.
Like PNGM, it is used primarily with WiFi (802.11).

When the MAC address changes, the station disconnects from the current session and reconnects using the new MAC address.
This will involve a new WPA/802.1x session: new EAP, TLS, etc. negotiations.
A new DHCP, Router-Advertisement will be done.
If DHCP is used, then a new DUID is generated so as to not link to the previous connection, and the result is usually new IP addresses allocated.




-- 
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide