Re: [STDS-802-11-TGBH] 46 or 44 bit IRMs

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

Mike,

If the SLAP policy allows random MAC addresses they would be randomly selected by the STA from the AAI quadrant, correct. But just because the policy enforces the AAI quadrant does not mean that it allows random MAC addresses. The AAI quadrant is for an administrator to have MAC addresses assigned in an "arbitrary fashion". That _could_ be "let the STA use 44bits for randomization" or it could be something else. Right? I do not believe that AAI is equivalent to "STA uses 44bits for randomization".

regards,

Dan.

"the object of life is not to be on the side of the majority, but to

escape finding oneself in the ranks of the insane." – Marcus Aurelius

On 6/3/24, 8:24 AM, "M Montemurro" <montemurro.michael@xxxxxxxxx> wrote:

Hi Graham,

My understanding is that if an 802.11 network that is configured with SLAP allows random MAC addresses, they would be randomly selected by the STA from the AAI quadrant. That was discussed at some point towards the end of 802.11aq.

Cheers,

Mike

On Mon, Jun 3, 2024 at 11:14 AM G Smith <gsmith@xxxxxxxxxxxxxxxxxxx> wrote:

Thanks Mike. Maybe you can also answer a related question on. If AAI is in use, can the non-AP STA still assign its own MAC address?

Graham

From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Monday, June 3, 2024 11:10 AM
To: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>
Cc: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] 46 or 44 bit IRMs

Hi Graham,

The SLAP policy is administered on a LAN basis. An 802.11 STA can be configured to connect to multiple LANs and it's up to the administrator of the LAN to apply the policy.

In REVme, we added an ANQP advertisement to allow a STA to discover whether a network is using SLAP. Clauses "11.22.3.3.16 Local MAC address policy procedure" and "9.4.5.29 Local MAC Address Policy ANQP-element" in REVme D5.0 describe these procedures.

Cheers,

Mike

On Mon, Jun 3, 2024 at 10:24 AM G Smith <gsmith@xxxxxxxxxxxxxxxxxxx> wrote:

Hi Jay,

Just one further thought on this. As Dan and Antonio are discussing, how SLAP is administered is a mystery to me in our 802.11 context, and I definitely am not the one to pontificate on that.

From: G Smith
Sent: Monday, June 3, 2024 10:15 AM
To: yang.zhijie@xxxxxxxxxx; STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBH] 46 or 44 bit IRMs

Hi Jay,

I may not be the best person to answer this but basically the MAC address is made up of 48 bits. However, bit 0 in the 1^st octet is the unicast/multicast bit, set to 0 for unicast. Bit 1 in the first octet is the global unique/locally administered bit. As was agreed for 11aq and in the baseline, all random MAC address must have this bit set to 1 so as to distinguish it from the unique assigned MAC address. Hence, we have 46 bits that IRM can set randomly.

Then along came SLAP which uses the next two bits, b2 and b3 in the 1^st octet to specify four quadrants: extended local (ELI), standard assigned (SAE), administratively assigned (AAI) and reserved. The proposal (by SA) is that the IRM should always be in the AAI quadrant so now we only have 44 bits that IRM can set to random.

I calculated the effect of having just 44 bits versus 46 on the probabilities of duplicates.   The results seem to indicate that it is still rare, but the chance of duplication is going to be at least 4 times worse with 44 bits than with 46 bits.

Not sure if I answered you question but I did my best :>)

Thanks

Graham

From: Jay Yang <yang.zhijie@xxxxxxxxxx>
Sent: Sunday, June 2, 2024 10:00 PM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] 46 or 44 bit IRMs

Hi Graham,

What's the exactly requirement to define 44 bits for IRM? Or do you propose to use totally 46-bit for MAC address? I'm not sure I get your intention. If you want to refine the length of MAC address, we could discuss it in 802.11me group, but it's out of 11bh scope. I'm still confused on the gain of 46-bit MAC address compared with 48-bit MAC address, as SYSTEM always process information based on unit of BYTE, but not BIT.

Thanks

Best Regards

Jay Yang (杨志杰)

Original

From: Harkins,Dan <daniel.harkins@xxxxxxx>

To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx>;

Date: 2024年06月01日 22:51

Subject: Re: [STDS-802-11-TGBH] 46 or 44 bit IRMs

Antonio,

I know it's "not for WLAN only." I said it's not being used in WLANs so the inference from that statement is that it must be for something other than WLAN.

But without any advertisement of SLAP policy—remember, SLAP is not just "44 bits for random MACs", there are other policies enforced in other quadrants—the STA can only assume there is no SLAP policy being enforced in the ESS and, hence, is free to use all 46 bits to create a random MAC address.

If we really want to bring SLAP into the TGbh draft we'll need to decide what IRM does for the 3 defined quadrants, not just assume 44 bits are always available. For instance, if the quadrant is "administratively assigned" then the STA can't just decide to use 44 bits for randomization because it's MAC is going to be assigned to it in a fashion that is entirely up to the administrator of the network. And in that case there is no need for IRM or Device ID, right? The STA is going to be identified by the MAC address it got administratively assigned. No need for TGbh!

This is what is known as a "can of worms", something you don't want to open up. I really don't think we want to bring SLAP into the TGbh draft.

regards,

Dan.

--

"the object of life is not to be on the side of the majority, but to

escape finding oneself in the ranks of the insane." – Marcus Aurelius

On 6/1/24, 1:44 AM, "ANTONIO DE LA OLIVA DELGADO" <aoliva@xxxxxxxxxx> wrote:

Hi Dan, I do not want to go into endless discussions here but please remember SLAP is not for wlan only, it is to enable future use of the local space in 802 technologies. So there maybe an application of SLAP in the wired part connecting your ESS, and by using the 46 bits you are not allowing other technologies to use it.

I think just going for 46 bits on the basis of wlan not using it right now, is a too wlan centric approach.

Br

Antonio

—
Antonio de la Oliva
Associate Professor, UC3M
Skype: aolivadelgado
Phone: +34916248803

El El vie, 31 may 2024 a las 22:59, Harkins, Dan <daniel.harkins@xxxxxxx> escribió:

Hi Graham,

I get roughly the same numbers for "results" (slide 8) but I do not agree with your interpretation. There is a problem when two STAs try to use the same MAC address. That probability is very remote. Even if, as you assume, 80,000 STAs associating (note, I believe the record for simultaneous associations in a single ESS is closer to 30,000 but let's plan for the future) and each one associates 3 times per day that does not mean there will be 15.75 duplicates per day because these 80,000 STAs are not running through their random MACs simultaneously. The probability of 2 STAs using the same MAC at the same time if there are 80,000 STAs associating is still 0.000045. It's not 1 (which 15 duplicates per day would imply).

And I agree with Mike. We can use all 46 bits for randomization. Nobody's doing the SLAP for 802.11 networks.

regards,

Dan.

--

"the object of life is not to be on the side of the majority, but to

escape finding oneself in the ranks of the insane." – Marcus Aurelius

On 5/20/24, 7:22 AM, "G Smith" <gsmith@xxxxxxxxxxxxxxxxxxx> wrote:

Hi TGbh’s,

At the Interim last week we discussed CID 3085 which proposed to define IRM as follows :

" A MAC address selected randomly from among the Administratively Assigned local identifiers specified in IEEE Std 802 and used by a non-access point (non-AP) station (STA) to identify itself to a network."

Using the AA designation means that the IRM would comprise 44 random bits as against 46 bits if we kept to the present “constructed from the locally administered address space”.

I had previously uploaded, but never presented, 23/2148r0 which looked at the theoretical probabilities of IRM duplicates for ESSs up to 80,000 stations using IRMs of 46 random bits. I have now posted r1 where I have added the results for IRMs of 44 random bits.

https://mentor.ieee.org/802.11/dcn/23/11-23-2148-01-00bh-probability-of-irm-duplicates.pptx

The results are:

For a busy ESS (network), with each STA associating 3 x per day, storing a high number of IRMs (80,000)

For 46 random bits:

–         Each AP (40) in ESS has a duplicate every 2.54 days

–         Each STA only experiences a duplicate every 14 years.

(i.e., Action frame exchange to get new IRM is a small overhead)

Notes: Assumed 2000 STAs per AP

For S1G (8000 STAs per AP), each AP has 1.57 duplicates per day.

For 44 random bits:

•         Each AP in ESS has a duplicate 1.57 times per day (i.e., 4 times more frequently)

•         Each STA experiences a duplicate every 3.5 years.

Note: For S1G (8000 STAs per AP), each AP has 6.3 duplicates per day

I do not intend to ask Mark for time to present this as it would probably take up a lot of valuable time. I have included all the formulas and derivations I used, so those interested can check my analysis and results, and of course, I welcome comments. The results are what matters as I have provided above. Of course if anyone feels that my assumptions of the maximum size (80,000) ESS should be different, or each STA should on average associate more (or less) than 3x a day, please let me know and I will run the numbers accordingly.

I leave it to the group to decide if the effect of reducing the random bits from 46 to 44 is significant enough that we could use it as a reason to stick with the “locally administered address space”, and not change to “selected randomly from among the Administratively Assigned local identifiers specified in IEEE Std 802.”?

Thanks

Graham

To unsubscribe from the STDS-802-11-TGBH list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1

To unsubscribe from the STDS-802-11-TGBH list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1

To unsubscribe from the STDS-802-11-TGBH list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1

To unsubscribe from the STDS-802-11-TGBH list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1

To unsubscribe from the STDS-802-11-TGBH list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1

To unsubscribe from the STDS-802-11-TGBH list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1