|Thread Links||Date Links|
|Thread Prev||Thread Next||Thread Index||Date Prev||Date Next||Date Index|
Responding more fully to Roger’s question on the role of the “company” owning the CID in MAC address assignment. Company is in quotes because in some cases the owner could be a standards body.
My main interest CID-based local addresses is d) something else – namely as the default block for an assignment protocol.
As I mentioned in my earlier note, some virtualization companies already use address blocks for this either by choosing a local address block on their own or by making local address assignments of global addresses, i.e. the addresses have the global/local bit indicating global but the addresses aren’t global.
INCITS T11 also chose local address blocks for its FCoE address assignment mechanisms.
I’ve proposed that IEEE 802.1 should do a more generic address assignment protocol – probably a pair of protocols: one for serverless address claiming and one for server address assignment. Having a generic protocol would be useful for some the IoT devices.
Native Fibre Channel does topology-based address assignment with a 24-bit address space. For a LAN, 24 bits is probably enough for most networks. For a larger network, an administrator could also assign additional blocks out of the local address space if more were needed.
Since some virtualization vendors and others have chosen blocks to use for their protocols in the absence of a way to get a local address block assignment, it would be helpful to compile a list of blocks already in use some (probably many) are not in the CID space so it would be helpful for local administrators and others to know which are already in use in case they want to avoid those blocks. Also, since some may be in the CID space, for the RAC to set a grandfathering period during which they will assign an entity the CID that they already use.
<RMG> On the privacy point, a CID based address is better than an EUI used as a MAC address as it is not repetitively used by a device (24-bits could still effectively be random) from the snooping point of view. If it were turned around and the CID is one used by the local address administrator, then the local MAC address that a device is using tell you nothing about that device. Using CID in diagnosis was not a consideration as far as I recall either during RAC discussions or in possible protocols I’ve heard described.
<RMG> If there were multiple DHCP devices in your house that didn’t communicate, that would be one way to allow both DHCP devices to not assign duplicates. I believe Fibre Channel Over Ethernet has sufficient specification (like DHCP) so that this would not be needed, but if the RA assigns the appropriate CID to FCOE, then no virtulization vendor or Internet of Things vendor would be assigning duplicates with the FCOE application.
<RMG> There are also possibilities that the function is more that of a software vendor, operator or other rather than a hardware manufacturer. (Though CID use in many of these cases is not for MAC addresses but rather for Context Dependent Identifiers.)
(b) The local network administrator? This seems to be like saying that every locally-assigned DHCP address in my house should have some bits that are unique to my house. What use is that? Local is local; what good is making it partially global?
<RMG> The most consistent policy for use of the local address space is that a local address administrator would assure no duplicates were created. That has existed since the early 1980s. IBM proposals back then indicated a preference for only using local addresses for 802.5 (16-bit ring number and 32-bit node number). That would have operated under this broad rule for the local address administrator. Perhaps I’m missing your point with the DHCP example here.
(c) An operator? For example, a gas meter has a gas company CID and an electrical meter has a power company CID on the same LAN. Seems like a problem better solved by VLAN,.
<RMG> VLAN isn’t the answer to duplicate addresses. I don’t recall VLANs being part of RAC considerations though.
(d) Something else?
<RMG> Where there is no standard to govern things, the CID allows private protocols that do not have to cooperate with other protocols. Obviously if p802c is successful, then it will be referenced by other standards and be used by private protocols rather than just picking local addresses for the application as is now sometimes done. CID of course has non-address uses that can reduce the consumption of OUIs. For example, some standards specify use of an OUI for non-address applications. I would guess though that this was not part of your concern here.
<RMG> Lots of possibilities here. How about 44 bits? One quadrant of the local space for the “wild west”, one for CID based automated assignment, one for … Realistically, the problem here is how to best accommodate the fact that the entire space is the “wild west” today, no rules other than some local administrator being responsible for preventing duplicates, but reality being that some uses of the local address space are in use. From my perspective, the RAC is really serious about not declaring other legacy uses “illegal”, something 46-bits probably could come closer to doing. I believe the RAC consensus is that any local address structuring will take years to get pushed into the marketplace. We started that by getting appropriate warning into IETF descriptions of 802 addressing and OUI and CID. We tried to get it into the revision of Std 802. We will work to get things tightened up in many IEEE standards that use the OUI registry especially other IEEE standards that use 802 addressing. But this is and will be a long process not solved by p802c even though I believe p802c helps with a solution. Any proposal that ignores the reality of legacy use and simply assumes local addresses are not in use, I believe is flawed, whether that assumption is in 802 or IETF or were to become a property of any standard that attempts to jump into the local address space.
My personal opinion is the primary RAC responsibility is to ensure the viability of its registries. The two I worry about most are OUI and EtherType. I also believe that IEEE Std 802 is the right place to standardize 802 style MAC addresses. The two are related but there is an important distinction in responsibilities. An IEEE 802c amendment will have been subjected to a balloting process open to all interested parties. A RAC policy isn’t subject to the same process.
<RMG> I disagree in principle. Such details are for a project to decide. To me, is there a reasonable solution (technical and economic feasibility) to bring structure to the local address space and make local addresses more usable for IoT, virtulization, etc. is the requirement for approving a PAR. Sometimes we write the PAR to standardize a solution, but that is not IEEE-SA policy. The PAR serves as an announcement to the world of activity being initiated to all interested parties, in other words, a PAR to address a problem or opportunity is really what is intended by IEEE-SA process. I’m expect I’ve overstated your position here, and I’ll leave it to the PAR proponents to accommodate provision of more detail.
---------- This email is sent from the 802 Executive Committee email reflector. This list is maintained by Listserv.