Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
--- This message came from the IEEE 802.11 Working Group Reflector ---
Hi Roger, I support the idea of a MAC addresss policy ANQP element to allow an AP to indicate any kind of addressing policy the network behind it is using. I do think some changes to your document are necessary, though, around the parts of this proposal that deals with randomized MAC addresses. If I, as an AP, wanted to indicate to the client that what we euphemistically called in 11aq "the wild wild west" of local address policy—i.e. no policy at all—and let the client randomize 46 bits of its address I would indicate it thusly (and please do point out if and where I'm wrong): - bit 4 of the MAC address policy bit bitmask is set to 1 - the MAC address prefix octets of the MAC address policy field is the value of 1 - the prefix trim field of the MAC address policy field is the value of 6 which is quite convoluted and unnecessarily complex. Since the MAC address policy bitmask is a bitmask of all the supported policies why not just put some text in your submission that if the value of the MAC address policy field (the bitmap) is 0 (meaning no bits are set) then there is no policy being enforced by the network and it is "the wild wild west" as far as MAC address randomization is concerned? It's much simpler that way and is more semantically correct—the message is "this is my policy" and if there is no policy it should be stated that way directly. My second comment is that having bit 4 of the MAC address policy field allow for any prefixes to be used (beyond the 1st one with 6 bits of trim) will increase the chance of MAC address collision for no apparent gain. If the policy was 3 octets of prefix and 0 bits of trim then there's 22 bits being used for randomization and that results in a 1:2 chance of collision for a moderately sized network of 2500 simultaneously associated clients. In other words, it's gonna happen. When the policy is 1 octet with 0 bits of trim (38 bits) the probability drops to 1:89,000. While that may seem comfortable, it drops to 1:22,500,000 (twenty-two and a half million) when using all 46 bits. Now what is the benefit of an 802.11 access network adding a prefix to a randomized MAC address? I don't see one. Why not just get rid of bit 4 from the MAC address policy field? If you want to allow randomization then indicate that by stating "no policy"? regards, Dan. To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1 |