Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue)
job at instituut.net
Fri Dec 2 19:50:40 UTC 2016
On Fri, Dec 02, 2016 at 09:32:37AM -0800, Leo Bicknell wrote:
> I also do not think this is an IEEE/MAC assignement problem. This is a
> vendor's box can't forward a particular payload problem.
On Fri, Dec 02, 2016 at 04:59:37PM +0000, Nick Hilliard wrote:
> Job Snijders wrote:
> > Dear IEEE, please pause assigning MAC addresses that start with a 4
> > or a 6 for the next 6 years.
> Disagree that this is an IEEE problem. This is problem that vendors
> need to work around. There is limited MAC space, and deprecating 1/8 of
> it due to the inability of vendors to cope properly with it seems like a
> really bad long term idea.
Yes the vendors are doing a poor job. I also appreciate the argument
that IEEE just manages that number space and we should consider these
'just numbers' and the vendors need to make do. On the other hand if
IEEE had just stuck to the original allocation plan, you and I wouldn't
be dealing with this garbage situation.
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?
IEEE could've shown more restrain by (temporary, until IPv4 is dead?)
avoiding 4 and 6 and still accomplished some of their goal (if this
dubious strategy even is effective).
I consider this a cascading failure. Clearly IEEE's change had a ripple
effect, and suprised a number of implementers, and ended up hurting us.
More information about the NANOG