Subject: [Madinas] github comments on internet-drafts

From: Michael Richardson <[email-masked]>
Date: Wed, 09 Mar 2022 17:59:26 -0500

Hi, we have adopted two drafts.  I wonder if they are in git?
markdown? xml?   I'd rather send typos and the like as pull requests.

I tried:
   https://github.com/ietf-wg-madinas

which is the RFC8875 recommended name, but it isn't setup yet.

Do the chairs intend to set that up?
Either way, are the drafts available?
(Let me know if I can help)

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

---

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 10 Mar 2022 14:15:04 +0000

Hi Michael,

Thanks for helping to review the drafts. I currently use (https://github.com/lightcable/madinas) for the use case draft. I will discuss with the chairs to create WG github space in soon future.

Best,
Yiu

On 3/9/22, 17:59, "Madinas on behalf of Michael Richardson" <[email-masked] on behalf of [email-masked]> wrote:

    I tried:

---

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Thu, 10 Mar 2022 19:50:16 +0100

Dear Michael,

We don't have a git repo yet, but we'll create one (
https://github.com/ietf-wg-madinas) and ask authors of documents to upload
them there.

Thanks for the suggestion!

CJ & JC

On Wed, Mar 9, 2022 at 11:59 PM Michael Richardson <[email-masked]>
wrote:

> Madinas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/madinas
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 29 Mar 2022 12:47:22 -0400

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.

---

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Tue, 29 Mar 2022 23:08:33 +0200

Hi Michael, all,

We already have the github organization created for MADINAS. I'm just going
through RFCs 8874 and 8875 to ensure we did everything following the IETF
guidelines. As soon as everything is set up, we'll ask authors to upload
the xml files.

Thanks for your kind offer to help. I'll probably ask you some things ;)

Thanks,

Carlos and JC

On Tue, Mar 29, 2022 at 6:47 PM Michael Richardson <[email-masked]>
wrote:

> This has been a 24-bit prefix (including two upper bits which are set
> specifically) that is assigned to the vendor.
> 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.
>
> 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.
>
> As there are often small interruptions in hand-over between access points,
> this MAC address usually needs to be kept for short times.
>
> When the MAC address changes, the station disconnects from the current
> session and reconnects using the new MAC address.
> 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.
>
>
>
>
> --

---

From: Michael Richardson <[email-masked]>
Date: Wed, 30 Mar 2022 12:47:05 -0400

> guidelines. As soon as everything is set up, we'll ask authors to upload

Cool.

    > Thanks for your kind offer to help. I'll probably ask you some things

What do you think about the taxonomy?
Which document does it even go into?

    >> ## Per-Period Generated MAC address (PPGM)

Maybe the word "Generated" should be dropped from the TLA.