Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue)

Tue Dec 6 13:58:11 UTC 2016

In a message written on Fri, Dec 02, 2016 at 08:50:40PM +0100, Job Snijders wrote:
> IEEE told one of my friends: "We changed our allocation methods to
> prevent vendors using unregistered mac addresses."
> 
> Does the cost of some squatters on poorly usable MAC space outweight the
> cost of the community spending countless hours tracking down where those
> dropped packets went?

That's the wrong question to ask.

The right question is, what could have been done to prevent this entire
situation?

This problem has occured in all sorts of number spaces before.
There have been squatters in almost every number space, boxes
"optimized" based on the pattern of allocation, code bugs that went
unnoticed due to part of the number space not being used.  It's
happened to MAC's, IP's, ports, even protocol numbers.

One of the answers is to better allocate numbers.  Starting at the
bottom and working up is almost never the optimal solution.  Various
sparce allocation strategies exist which insure a wider range of
addresses are used early, there is a greater chance of wacking a
squatter early, and that the number space ends up more efficiently
used in many cases.

Had the IETF allocated a MAC starting with 0 then 2, then 4 then 6
then 8 then 10 then 12 then 14 this problem would have likely been
identified early on in vendor labs when testing the pseudowire code
and would have prevented the "hack" of looking deeper in the packet
and guessing because too many 4 and 6 MACs were already deployed.

-- 
Leo Bicknell - bicknell at ufp.org
PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20161206/7c1cdb9d/attachment.sig>