Re: [nvo3] Number assignments

<Pat Thaler with my member of the IEEE RAC (Registration Authority
Committee) hat>

If the RAC gave 256 Ethertypes to an IETF protocol, then we would be likely
to also get requests from other entities for multiple allocations. Yes,
 under the current requirement for using subtyping to prevent multiple
allocations, we have been going through Ethertypes very slowly and the
space will last for a very long time. But the alternative of removing that
requirement could allow fast exhaustion of the space. In my opinion, an
exception is extremely unlikely.

On Tue, Jul 25, 2017 at 7:26 PM, Dale R. Worley <worley@ariadne.com> wrote:

> Donald Eastlake <d3e3e3@gmail.com> writes:
> > Nevertheless, it is my opinion that it would be EXTREMELY difficult to
> > get an allocation of even tens of Ethertypes, let alone hundreds, from
> > the IEEE Registration Authority. I would suggest a different approach.
>
> I expect that you're right as a bureaucratic matter.  But technically,
> it shouldn't be a problem.  There are 3489 Ethertypes assigned
> (according to the IEEE's file), which is 5.3% of the number space --
> assigned over the 37 years since 1980.  At this rate, they should last
> till around 2292 C.E., though my proposal would pull that date in to
> 2290.
>
> > Maybe you could use Ethertype 0x88B7. This indicates an extended
> > Ethertype where the actual type is given by an OUI and a further two
> > bytes referred to as a SNAP protocol number. IANA already has an OUI
> > and very few of the SNAP protocols under it have been assigned (see
> > https://www.iana.org/assignments/ethernet-numbers/
> ethernet-numbers.xhtml#ethernet-numbers-6)
> > so it would be easy get a block of 256 SNAP protocol number under the
> > IANA OUI. However, it is not clear where the OUI+ 2 bytes would go
> > and, since this is an Ethertype defined by and under the control of
> > IEEE 802.1, it would be a problem to the extent that this was a
> > different use.
>
> Anoop Ghanwani <anoop@alumni.duke.edu> writes:
> > I think the IEEE-recommended way to solve this problem is to use
> subtyping.
> >
> > This means IEEE will give IANA just _one_ Ethertype to be used for "Next
> > Protocol Identification in Geneve".  IANA in turn issue subtypes for as
> > many protocols as need to be indicated.  The way this works then is that
> > the Geneve next protocol field would indicate an ethertype of "IANA
> > assigned subtype" and then we need to look at the next two bytes to
> figure
> > out which protocol is being carried in the frame.
>
> Another way out of this is suggested by this passage from Wikipedia:
>
>     In order to allow some frames using Ethernet v2 framing and some
>     using the original version of 802.3 framing to be used on the same
>     Ethernet segment, EtherType values must be greater than or equal to
>     1536 (0x0600).
>
> If that is true, we could carry an IP protocol number in the Geneve
> Protocol Type field by putting 00 in the high byte and the IP protocol
> number in the low byte, as there are supposed to be no Ethertypes less
> than 0600.
>
> (The IEEE registrations allocate all of 0101-01FF to "Xerox
> (experimental)"; 0200, 0201, and 0400 as "Private"; and 0500 to "Sprite
> RPC" and also to "University of Berkeley" (which seems to mean UC
> Berkeley).  But none in the block 00xx.)
>
> Dale
>
> _______________________________________________
> nvo3 mailing list
> nvo3@ietf.org
> https://www.ietf.org/mailman/listinfo/nvo3
>