[192971] in North American Network Operators' Group
Re: Forwarding issues related to MACs starting with a 4 or a 6 (Was:
daemon@ATHENA.MIT.EDU (Leo Bicknell)
Tue Dec 6 08:58:18 2016
X-Original-To: nanog@nanog.org
Date: Tue, 6 Dec 2016 05:58:11 -0800
From: Leo Bicknell <bicknell@ufp.org>
To: nanog@nanog.org
Mail-Followup-To: nanog@nanog.org
In-Reply-To: <20161202195040.GG513@Vurt.local>
Errors-To: nanog-bounces@nanog.org
--uAKRQypu60I7Lcqm
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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."
>=20
> 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.
--=20
Leo Bicknell - bicknell@ufp.org
PGP keys at http://www.ufp.org/~bicknell/
--uAKRQypu60I7Lcqm
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIVAwUBWEbD8rN3O8aJIdTMAQLRvw/9E3gACxrRMaYbvtjUax9T4izKOOHB9Xxp
U3i+hSCyXRkDzm/QHSOHJEyBKMykNfvPkLbC1yT/tzkQYeRQDQ27lWZXtOVPn+Fx
18yDggTFLa0UemleuXhaf/gYlm4NyJmavqWNIAh7oC6Ulf3Qu6Kx6EM+b3cn3VtM
pz2pOVu0PMUZlNW/Qf8ChhgzpB90xE53U9Z4Fvw1Nd8U8PEx/gL1YKbQ4iMuqa31
8mBI3yuEhcxOsi3MQCZwlEiHkldeBRDtX99wlzAd8G0hTd1JXsP91GkByRMsUtcE
YTwH6qaR5il/7Z/EV0yp3k/OUhoYIjxQiIOopOBW91fv61mjJbWGW0gdlaCLJh8G
mbZXrtZ3/ZZxxnOa52jAXUpt/DBUaSwBDtzNqnVdqwF8V4gIKyvmBdWae3yhSfgI
2Vfw+sqVmxd23npFlcPqnX4xE6ehSrFiyH5c35Pa2sP7vFBWTK6VNbCMVgPjaXdc
Tf+Mmb3GDsgNZKSVoZQng1BZvyxts9aeV5w5hI1u8ccNeWKosiiJfgwAGg3VF96L
BI2SZz/3sanpeTr57y0rmwPGBIdmPKtNMnekKVzLKM1g8Xosx/Ij+syL4sJTSfVl
hk5vHQQKyOvwVXM3dMbnmmlxBb+Cmn5p4jZha2T3jBozuBdOhgbgdzqTUGaRcFfE
92xTxpuT77U=
=e9gy
-----END PGP SIGNATURE-----
--uAKRQypu60I7Lcqm--
