|Thread Links||Date Links|
|Thread Prev||Thread Next||Thread Index||Date Prev||Date Next||Date Index|
Like Bob, I’m not speaking for the RAC. I’m not a RAC member but I have been participating as an observer based on my background in data center networks.
I’ve been working with the RAC on trying to address the needs for making the Local Address space more usable for address acquisition without configuration for a few years now. There was no good solution at the time. One had a choice to either:
1. Get a global address block where you were assured that no one else would conflict with your assignments but where you were misusing it by making address assignments out of it that were local, or
2. Squat on a portion of the local address space, counting on low usage of the local address space and your customers being aware of what portion you were using to avoid conflicts.
The concern initially arose because some virtualization vendors were buying OUI blocks for their virtualization orchestration systems to assign addresses to virtual machines(VMs) because they couldn’t “own” a block in the local address to assign addresses; i.e. alternative 1.
INCITS T11 also ran into this problem when defining a protocol to assign addresses to virtual FCoE ports. In that case, the group chose blocks in the local address space
for their protocol. Like some virtualization vendors, they chose alternative 2.
You can see this presentation to the IEEE 802 / IETF leadership meeting on the topic:
and this Internet Draft:
To protect the global address space, we needed a way for protocols to have a local address block that doesn’t need configuration. The text that Roger points out below in the EUI tutorial reflects that work. CIDs are being assigned out of one quadrant of the local address space. However, that text is very brief and more guidance is needed to help people use the local address space without conflicts between the various users including those doing local administration of addresses.
The rise of IoT intensifies these concerns because
· many IoT devices will be deployed into environments where configuration is problematic,
· the number of IoT ports created is likely to be orders of magnitude greater than the existing address users
For more on this, please see these presentations:
Yes, it is difficult to provide structure to something that previously has not had structured use. There may be some networks where administrators are making assignments out of the CID block area. The RAC tried to choose an area that makes this less likely. Fortunately, use of locally administered addresses isn’t very common today. In any case, bringing structure will not get any easier by waiting. My position is that we need to start this now before the problem gets worse.
Regarding Dan’s statement: “namely
Some local administrators may need to transition the part of the address space that they are using in order to be compatible with the new structure. I don’t expect that the PAR will make their existing usage “illegal”. I think that we are likely to acknowledge that the structure is being imposed on an address space where there is existing non-structured use and will be recommendations rather than “shalls”. I.e. if a local administrator wants to be able to deploy protocols using CID blocks, they should administer their locally administered assignments to use the portion recommended for local administration and change any that are in the portion for CID use.
The new group will not be allocating the portion of addresses for these assignments. The RAC already did that in choosing the CID block space.
Regarding the recommendations in 11-14/0367r2, as far as I know, there was no attempt to coordinate those recommendations with the RAC. The would conflict with current local administration of MAC addresses and no transition plan is discussed in the recommendation which assumes that it can use the whole Local Address space.
With any random assignment mechanism, there should have a claiming protocol that detects and resolves address collisions. By making the random address space, you reduce the risk of a collision but multiplied by the number of networks, there will remain a reasonable probability that there are some collisions on some networks and those need to be resolved. Yes, with 24 bits, a small number of nodes may need to try more than once to get an address assignment but having more than 3 claim attempts will be very rare.
Even taking Dan’s number of
p(5000, 2^24) = 0.525, that is the chance that one pair amongst the 5000 nodes gets an address conflict. One of those nodes will have to make a 2nd claim attempt which will have only a 0.0003 chance of conflicting with the 5000 assignments.
The probability that it fails to succeed by a 3rd attempt is 9e-8.
There would also be the alternative in a large network of having an address server which would supply an address with no conflicts.
My thoughts currently are that address claiming in a 2^24 address block and address serving in a 2^24 address block will serve the needs, but if discussion in task group reaches a consensus that there is also a need for a larger random address space, we could discuss whether a quadrant (2^44 addresses) should be designated for that.
Roger, and others:
Please see inline comments, responses to questions below. (Again, everything is personal opinion, not RAC position.)
On Oct 8, 2014, at 12:02 PM, Roger Marks <email@example.com> wrote:
I share many of Dan's concerns about partitioning the local space.
<RMG> If a vendor for example is creating virtual machines, if they use their CID, it will by definition be unique from any other vendor using their CID as the basis for creating local addresses for virtualization or any other purpose. There doesn’t have to be a single address administration function. Other thoughts of RAC members (no policy on any of this that I recall):
1. If only a portion of the CID space is used for automated assignment, then we can reserve another portion to be the “wild west” where a Local Address administrator still has free reign.
2. We can gather up and publish somehow a list of local addresses that people have assumed to be usable. Some local addresses are specified in standards.
3. We can consider giving priority to current OUI assignees to get the corresponding CID (numbers only differing by the U/L bit). This would legitimize those users that assumed (they had rights to do this). (Big debate should we reaward someone that just assumed rights that weren’t expressly granted?) BTW, The RAC administrator just received a question last month stating the assumption that they had rights to flip the U/L bit of an assigned OUI and nobody else would be assigning a Local Address with that value—nothing that RAC policy suggests they could assume but not uncommon.
<RMG> What of any of this RAC thinking/discussion would be included in the p802c draft is not an issue for the PAR, but rather for draft development and balloting. BTW, it wasn’t only RAC thinking, but 802.1 and IETF that contributed to launching the CID recognizing possibilities for use in automated local address creation.
<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.