Forwarding issues related to MACs starting with 4 or 6
seclists.org
seclists.org
[1] https://www.symantec.com/connect/forums/firewall-incorrectly...
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=599161 https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=5991...
I remember it was patched and out by debian right around Christmas; quite the present. This bug made me feel very helpless. I recall there being more information around the circumstances of its discovery on the Xen mailing list.
Source: worked at Stanford in IT
TIL: MAC squatting is a thing.
IEEE's new policy is uncomfortable in another way, it makes it impossible to guess what a new, not-seen-before MAC prefix might be.
Not sure why you'd otherwise want a list of never-before-seen OUIs
There you go, straight from the source. Convert that to whatever your scanning tool wants and you can update your list as often as you feel necessary.
No need to make assumptions about unknowns when you can just make them known.
This reminds me a little of what Mr. Prosser said to Arthur Dent in the Hitchhiker's Guide to the Galaxy about the demolition notice for Arthur's house: "It was on display at the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying beware of the leopard."
You can't make the assumption that engineers will be able to keep all of this in their heads. The IEEE is not going to review every document and put together a compendium of bear traps awaiting them in the future, and they aren't going to review every historic document before every decision, either.
If the few that knew what would happen made an incorrect assumption of prior knowledge, then they dropped the ball in reminding those that needed to know.
Since nobody remembered, they should have just been informed of the mistake and a possible solution or assistance provided.
So if it gets an ethernet frame destined for your address starting with 4 or 6, it will think it's actually an IP payload, and discard it because it doesn't validate as a IP packet or otherwise misdirect it.
Edit to add: In MPLS networks, 'P routers' (core routers) by design don't know if the payload is Ethernet or IP; but may want to peak into the payload to do hashed traffic balancing or validating packets before forwarding. Hashing the packet as an IP packet when it's an ethernet packet is problematic because you want all packets on a given TCP connection to have the same hash value -- but since you misidentified the type of packet, the bytes used as input to the hash aren't static for a given connection so different packets in the connection may take different paths and may arrive out of order.
Obviously in hindsight this is a bad idea and "idiotic", but I can't see the immediate fault of whomever first decided to try this a decade ago when MAC addresses were sequential, IPv4 was fairly abundant, and we didn't really even have smartphones and the explosion of connected devices.
Here is a list of all the ethertypes it cares about: http://www.networksorcery.com/enp/Protocol/802/ethertypes.ht...
Fire up wireshark and you will see these.
Where is this going? Who is trying to turn LAN into WAN and why?
I must come across as dense but Ethernet > MPLS > Ethernet feels like a "let's start over" moment.
in other words, it's cheaper than making your customer buy a bunch of weird proprietary network equipment to hook up their office wifi.
https://tools.ietf.org/html/bcp128
"any application that defines an FEC that does not take measures to prevent the values 0x4 and 0x6 from occurring in the first nibble of the payload may be subject to IP ECMP and thus having their flows take multiple paths and arriving with considerable jitter and possibly out of order."
"In the early days of MPLS, the payload was almost exclusively IP. Even today the overwhelming majority of carried traffic remains IP. Providers of MPLS equipment sought to continue this IP ECMP behavior. As shown above, it is not possible to know whether the payload of an MPLS packet is IP at every place where IP ECMP needs to be performed. Thus vendors have taken the liberty of guessing the payload. By inspecting the first nibble beyond the label stack, existing equipment infers that a packet is not IPv4 or IPv6 if the value of the nibble (where the IP version number would be found) is not 0x4 or 0x6 respectively. Most deployed LSRs will treat a packet whose first nibble is equal to 0x4 as if the payload were IPv4 for purposes of IP ECMP.
A consequence of this is that any application that defines an FEC that does not take measures to prevent the values 0x4 and 0x6 from occurring in the first nibble of the payload may be subject to IP ECMP and thus having their flows take multiple paths and arriving with considerable jitter and possibly out of order."
You can pretty much carry "Any Transport over MPLS" (AToM). As mentioned, IP is the most common protocol, of course, but you can "tunnel" almost anything you can think of over an MPLS path: Ethernet, ATM, PPP, HDLC, SONET, etc. Basically, you dump a frame into one side and it comes out the other unmodified -- regardless of the network in between.
As noted in the linked e-mail, an ISP providing (layer 2) transport has (little to) no control over the payload so there's nothing they can do to prevent running into this issue.
That's already a locally-administered address as the first byte ends in the hex nibble 'A'.
Aside from that, the IEEE's actions are a little odd here, but when you read BCP128[1]; you can see, it's really not their fault. This is due to vendors choosing a wacky and poorly thought out mechanism for identifying packet types on MPLS networks.
Certain routers are processing both IP packets and ethernet frames through the same logic. They want to know which it is. Ethernet frames start with the destination mac address, which used to be sequential and reaching higher numbers seemed far away so most started with 0 or 1. IP packets start with the IP version, so they're 4 or 6.
As a result, some vendors basically implement the following:
def is_ethernet_frame(data):
return not (data.startswith(4) or data.startswith(6))
os.name.startswith('Windows 9')
That reasoning was broken as it assumed sequential assignment is the only way to go.
"I believe IEEE changed their strategy to attempt to purposefully higher the chance of collisions with MAC squatters, to encourage people to register and pay the fee"