Re: [802SEC] P802c PAR [was Re: [802SEC] FW: [STDS-802-11] Fwd: [802SEC] IEEE 802 Nov 14 Plenary - "PARs under Consideration" Posted]
My understanding of the RAC discussions is that the consensus of their discussion is that addresses in the global address space is not okay and they have turned down some requests for address blocks where they understood the block was being requested for this purpose (but they didn't always know that a request was for a block to be used this way so some have gotten blocks that they use this way). If you want to question whether that is RAC policy then you should ask the RAC. They get to decide what is appropriate use.
An effective duplicate address check mechanism assumes that all nodes using that address space are participating in it. Nodes with locally administered addresses configured by an administrator aren't likely to participate. The same applies to using a proprietary server-based address assignment protocol such as one from a virtualization vendor or a standardized server-based protocol such as the one for FCoE.
The servers in a server based protocol can know how to check for other servers in that protocol and coordinate their use of the space the protocol is using. That isn't the case for talking to servers for another protocol.
Those using a server-less address assignment protocol will understand the duplicate address check mechanism that is part of their protocol but are unlikely to be able to understand the duplicate address check or claiming packets from other protocols. For example the VN2VN address claiming protocol in FCoE defines its own probe and claim address frames - it doesn't look for any other kind of duplicate address claim protocols.
Not all uses of address acquisition protocols will have a local administrator to keep them from conflicting.
Developers of address acquisition protocols have found it desirable or necessary to have a default block assigned. I strongly disagree with your statement. Not having that capability will cause problems for the protocols. When we define part of the space for block assignments, it still leaves ample space for local administration and other purposes. Those large networks that need additional blocks can have a local administrator assign additional blocks to the address servers out of the local administration quadrant. Large networks are more likely to use a server-based mechanism than a serverless one.
-----Original Message-----
From: Dan Harkins [mailto:dharkins@arubanetworks.com]
Sent: Monday, October 13, 2014 11:58 PM
To: Pat Thaler; STDS-802-SEC@LISTSERV.IEEE.ORG
Subject: Re: [802SEC] P802c PAR [was Re: [802SEC] FW: [STDS-802-11] Fwd: [802SEC] IEEE 802 Nov 14 Plenary - "PARs under Consideration" Posted]
Hi Pat,
On 10/13/14 11:49 AM, "Pat Thaler" <pthaler@BROADCOM.COM> wrote:
>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.
>
An address assignment protocol does not need a default block. How
addresses
get assigned by that protocol are a completely local decision and
completely
local decisions do not justify partition of the local address space or
assignment
of blocs of that space to particular purposes.
>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.
Whether or not this practice (making local address assignment with the
U/L bit
indicating global) is proper or not, it really illustrates that the
practices of
virtualization companies for address assignment are local. People can use
address
blocks on their local network in whatever way they feel is best for them
(they
are responsible for administering their LAN after all) and it should have
no impact
on anyone else.
>
>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.
And I have stated in the past what a good idea this is. I support your
proposal to create such a generic address assignment protocol.
For server-less address claiming, there will be some kind of conflict
resolution to address the possibility of a claimant making a claim on
an address already in use. And this will have to happen whether the local
address space is partitioned or not. If fact, partitioning of the local
address space will _vastly_ increase the probability of the conflict
resolution needing to be performed. If the local address space is not
partitioned, and claimants make their claim from the entire 2^46 addresses,
the the probability is _significantly_ less. So the only thing partitioning
of the local address space does is to make problems that need resolution
more probable.
For server assigned addressing, how the addresses are selected for
assignment
by the server is entirely up to the server. It can decide to grab a bloc of
the local address space to assign to devices or it can decide to use the
entire 2^46 local addresses to assign to devices. It really is a local
matter
and doesn't have any impact on the server assignment protocol running on a
different LAN (they could both decide to allocate addresses out of the same
block of the local address space). So partitioning of the local address
space
has no impact on server assigned addressing.
Partitioning of the local address space, or assigning blocs of addresses
for some particular purpose will either have a negative impact or no impact
on address assignment depending on whether it is server-less or no,
respectively.
In other words, there is no upside to partitioning of the local address
space or assignment of blocs of addresses to some particular purpose but
there
is a downside. So let's not do it.
>
>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.
"the absence of a way to get local address block assignment"? There is
no problem
caused by this absence. If a virtualization vendor wants to use the local
address
space then it is free to decide how it wants to use them on the local LAN
and the
administrator of the LAN is responsible for it. We can make the
administrator's life
easier once the address assignment protocol is defined but assignment of
local address
blocks is not a solution to any problem, it is just a cause of more
problems.
regards,
Dan.
>
>
>From: ***** IEEE 802 Executive Committee List *****
>[mailto:STDS-802-SEC@ieee.org]
>On Behalf Of ROBERT GROW
>Sent: Wednesday, October 08, 2014 2:25 PM
>To: STDS-802-SEC@LISTSERV.IEEE.ORG
>Subject: Re: [802SEC] P802c PAR [was Re: [802SEC] FW: [STDS-802-11] Fwd:
>[802SEC] IEEE 802 Nov 14 Plenary - "PARs under Consideration" Posted]
>
>
>
>
>I'd like to understand the perceived role of the "Company" owning the CID
>used in a MAC address. Is it:
>
>(a) The device manufacturer? This seems to be like saying that every
>locally-assigned DHCP address in my house should have some bits that are
>assigned based on the manufacturer. What use is that? [OK, diagnosis may
>be a little more convenient if an OUI happens
> to correspond to the name brand on the device, but that's a trivial
>advantage, and it's a disadvantage for privacy.]
>
>
>
>
>
>
><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.
>
>
>If I were a network administrator, I might see value in partitioning the
>local space following the IP model; in other words, on the basis on
>topology, so I could make forwarding decisions on the basis of a subset
>of the address and not need to store every MAC
> address in a switching table. But, if I were going to implement such a
>system, I'd want to locally administer 46 bits, not 24.
>
>
>
>
><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.
>
>I think that the PAR and CSD need to provide a clear indication of the
>expected usage model, articulating its advantages and disadvantages.
>
>
>
>
><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.
>
>
>
>I agree with Adrian that a forum at the Plenary would be very helpful.
>
>Roger Marks
>EthAirNet Associates
>
>
>ROBERT GROW wrote:
>I'd like to clarify/correct a couple points in Dan's email. (Personal
>comments, not comments from the RAC.) 1. Talking about what the CID has
>been historically is a bit misleading. The CID has very little history,
>only having been introduced this year. The RAC has never stated what it
>would not be used for, contrary to a possible inference from the
>assertion that the CID was ONLY for non-address applications. I'm not
>aware of any RAC statement or document that says a CID shouldn't be used
>for local address assignment. 2. The possibility of using a three-octet
>value with the U/L bit set as the base for local address assignment has a
>very long history independent of any RAC policy supporting the practice
>(nor RAC policy to prevent such practice). (Some have assumed and
>standards have even specified local addresses based on setting the U/L
>bit of an assigned OUI.) 3. The possibility for recommended practices or
>standards specifying use of a CID in assigning a local address was a RAC
>consideration in recommending to the BOG that a CID product be
>introduced. So, the idea underlying p802c is consistent with RAC
>considerations in development and introduction of CIDs. 4. I would
>expect RAC members (me for one) and perhaps even RAC mandatory
>coordination comments would object to anything in p802c that declares
>legacy uses "illegal". I find nothing in the p802c PAR that indicates
>the specifications would do this. On the contrary, all presentations I
>have seen for "automated" assignment of local addresses (rather than
>assignment by a local address administrator), except for pure
>randomization, recognize and deal with duplicate local address assignment
> These proposals recognize legacy use of the local space, and minimize
>the impacts of duplicate addresses on network operation. Bob
>Growbob.grow@ieee.orgM: 858 705 1829 On Oct 6, 2014, at 11:09 PM,
>"Stephens, Adrian P" <Adrian.P.Stephens@INTEL.COM>
><mailto:Adrian.P.Stephens@INTEL.COM> wrote:
>Dear EC, Feedback from Dan Harkins. His argument makes sense to me.I'd
>like to see a forum at the Plenary where this discussion can take place.
>Best Regards, Adrian P STEPHENS Tel: +44 (1793) 404825 (office)Tel: +44
>(7920) 084 900 (mobile, UK)Tel: +1 (408) 2397485 (mobile, USA)
>----------------------------------------------Intel Corporation (UK)
>LimitedRegistered No. 1134945 (England)Registered Office: Pipers Way,
>Swindon SN3 1RJVAT No: 860 2173 47 -----Original Message-----From: ***
>IEEE stds-802-11 List *** [mailto:STDS-802-11@ieee.org] On Behalf Of Dan
>HarkinsSent: 06 October 2014 18:27To:
>STDS-802-11@LISTSERV.IEEE.ORGSubject: Re: [STDS-802-11] Fwd: [802SEC]
>IEEE 802 Nov 14 Plenary - "PARs under Consideration" Posted --- This
>message came from the IEEE 802.11 Working Group Reflector --- Hi Jon,
>Thank you for the opportunity to comment on one of these PARs. I have
>serious problems with the 802c PAR. This proposes forming a group to
>partition and allocate portions of the local address space (those
>ethernet addresses with the "local" bit set to 1). Currently the local
>address space has 2^46 entries in it (48 bits with local bit = 1 and
>broadcast/multicast = 0).There are a number of issues with this plan.
>First of all, the IEEE RAC has been assigning OUIs for
>years.Historically, with an OUI an assignee also got 2^24 unique
>addresses assigned (an MA-L). Now the IEEE RAC is requiring first-time
>applicants to apply for a MA-M or MA-S first, providing 2^20 or 2^12
>addresses, respectively. In any event, purchasing of an OUI gets an
>assignment of globally-unique addresses. Also, the IEEE RAC will sell a
>"company ID", or CID.CIDs are intended for "non-address applications"
>such as protocol identifiers or context-dependent identifiers and
>assignees get a total of zero addresses, which makes sense (non-address
>application gets no addresses). These CIDs look just like OUIs, they are
>24 bits, except if you were to construct an address out of a CID it would
>be in the local address space because the difference between an OUI and
>CID is a bit which maps to the "local" bit. This has not been a problem
>historically because CIDs are for "non-address applications" and you
>should not be forming addresses out of CIDs so there could be no
>conflict. This PAR wants to allocate a portion of the local address
>space using IEEE RAC assigned CIDs. It actually wants to form addresses
>out of things that have been assigned for non-address applications. That
>does not seem to be consistent with the past or current practice of the
>IEEE RAC. And it creates new problems that IEEE RAC assignment of CIDs
>did not used to have, namely devices that use the local address space
>today may now become "illegal" as they will infringe on addresses this
>802c group may allocate if the PAR is approved. Another problems is that
>applications that want to randomize MAC addresses, for example following
>the recommendations from 11-14/0367r2, the probability of a collision of
>randomly-chosen MAC addresses must be kept as remote as possible.
>Partitioning the local address space will vastly increase the probability
>of collision and when there's a collision of MAC addresses on a network
>there are networking problems. Randomly-chosen MAC addresses do not need
>to be globally unique, they just need to be unique on the
>locally-switched network. As soon as a router is reached the addresses
>don't matter-- i.e. a device on the other side of the router could choose
>the same MAC address as my device does and that's not a problem. Using
>the birthday paradox we can tell the probability of a collision p(N:C)
>with C being the number of MAC addresses available to choose from and N
>being the number of STAs on a locally-switched network. How many STAs can
>we expect? Well for a small IEEE/verilan kind of network it's going to be
>less than 5000. The record for the largest 802.11 deployment is 30,000+
>simultaneous STAs seen (Levi's Stadium in Santa Clara, CA at a 49ers
>game). If the entire local address space is available we get: p(500,
>2^46) = 0.0000000018 p(1000, 2^46) = 0.0000000071 p(5000, 2^46) =
>0.0000001776 p(10000, 2^46) = 0.0000007105 p(30000, 2^46) = 0.00000639
>(about 1:156,000) p(64000, 2^46) = 0.0000291 (about 1:34000) Keep in mind
>that modern switches don't really function too well when the forwarding
>table gets too big (which is why vendors recommend it not get bigger than
>32k even though the theoretical max is 64k). If the 802c PAR requires
>randomly choosing based on a CID we end up with: p(500, 2^24) = 0.0074
>p(1000, 2^24) = 0.029 p(5000, 2^24) = 0.525 and that's already worse than
>a coin flip, for just 5000 STAs. Actually, the probability of collision
>for an average home network with the 802c partitioning, p(15, 2^24), is
>about the same as it is for the largest 802.11 network ever without the
>802c partitioning, p(30000, 2^46). So this PAR will guarantee that
>collisions will happen constantly on even the smallest 802.11 network.
>This PAR will guarantee chaos on a network of any reasonable size. To
>sum, this PAR will create problems with the way the IEEE RAC has
>historically allocated CIDs (they are for non-address purposes and you
>get no addresses) and it will guarantee chaos on switched networks. Well
>what problem does this PAR solve if it's producing all these problems you
>ask? It doesn't look like it solves a problem. It says that
>"[i]ncreasing use of virtual machines and Internet of Things (IoT)
>devices could exhaust the global address space if global addresses are
>assigned. This project will enable protocols that automatically configure
>addresses from a portion of the local address space. Such protocols will
>allow virtual machines and IoT devices to obtain a local address without
>local administration." But these devices can already automatically
>configure addresses from the local address space by just choosing
>randomly and the probability of collision is very remote. This PAR is
>actually describing a non-problem-- IoT devices cannot obtain local
>addresses without local administration-- and then proposing to create
>huge problems because of it-- partitioning of the local address space.
>I am strongly opposed to this PAR. IEEE 802 should not be approving
>groups that will cause huge problems on networks, especially when they do
>not appear to provide any tangible benefit. Thank you for giving me this
>opportunity to express my opinion on the 802c PAR. Regards, Dan.
>
>
>
>---------- This email is sent from the 802 Executive Committee email
>reflector. This list is maintained by Listserv.
>
>
>
>
>
>
>---------- This email is sent from the 802 Executive Committee email
>reflector. This list is maintained by Listserv.
>
>
>---------- This email is sent from the 802 Executive Committee email
>reflector. This list is maintained by Listserv.
----------
This email is sent from the 802 Executive Committee email reflector. This list is maintained by Listserv.