
Forwarding issues related to MACs starting with 4 or 6 - RiderOfGiraffes
http://seclists.org/nanog/2016/Dec/29
======
wolfgang42
I wonder how many bugs there are like this in low-level networking
infrastructure that cause issues which go undiagnosed for _years_ before
someone with enough knowledge to diagnose them figures it out. I keep reading
about weird networking glitches triggered by specific bit patterns, but
certainly if I ever encountered such a think I don't think I'd be able to
diagnose it.

~~~
qb45
One WTF I've seen: a consumer router which failed to NAT outgoing packets if
their endian-swapped destination IP matched the LAN subnet, i.e. anything sent
to X.1.168.192 would be forwarded to WAN with 192.168.1.Y source IP and get
lost. Took me a few weeks to figure out why certain random websites don't
work.

~~~
heywire
Reminds me of an issue [1] I ran into with Symantec Firewall looking at UDP
fragments as if they were full packets, and blocking them if the value where
the port number would be on a full packet matched a rule.

[1] [https://www.symantec.com/connect/forums/firewall-
incorrectly...](https://www.symantec.com/connect/forums/firewall-incorrectly-
blocks-fragments-udp-traffic)

------
TeMPOraL
> _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._

TIL: MAC squatting is a thing.

~~~
greglindahl
Whenever you have any kind of assignment process, people will squat. If
there's a monetary fee involved, more people squat.

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.

~~~
dfc
Why is it a problem to nit be able to guess a never seen before MAC prefix?

~~~
greglindahl
If I have a network scanning tool that tells me what's on my network, it's
nice to know that an unknown prefix is likely an Apple product, or an HP
printer, etc etc.

~~~
wolrah
[http://standards-oui.ieee.org/oui/oui.txt](http://standards-
oui.ieee.org/oui/oui.txt)

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.

~~~
greglindahl
Last time I did this, I found that the downloadable list ran behind reality.
That was 2007, maybe it's updated more quickly these days.

~~~
dfc
I have never looked up a MAC and had it not show up. Maybe in 2007 you were
using an old copy of the file that came with your distribution.

------
job
Good news everyone, Cisco re-examined the bug and concluded this particular
problem was not a hardware issue after all but can be remedied with a software
update:
[http://mailman.nanog.org/pipermail/nanog/2016-December/08941...](http://mailman.nanog.org/pipermail/nanog/2016-December/089416.html)

------
gkafkg8y8
> "This 4/6 MAC issue was well documented in BCP128 back in 2007. The control-
> word drafts mentioned that there would be dragons related to 4 and 6 back in
> 2004."

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.

------
kibwen
Can someone more knowledgeable explain why the digits 4 or 6 specifically
would be causing issues?

~~~
toast0
Ethernet frames start with the destination mac address, IP payloads start with
the version. It appears that in some networking equipment, there are places
where it may have a ethernet frame or an IP playload and uses the first four
bits to determine: if it starts with 4, it treats it as IPv4, and 6, IPv6.

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.

~~~
IshKebab
Wow that is idiotic. How can you be skilled enough to program routers and
still do something as obviously wrong as this?

~~~
wmf
In this case there simply isn't enough information in the packet to do the
right thing so it's a question of choosing which wrong thing to do.

~~~
uxp
Seems like an attempt at being "clever". L2 equipment shouldn't care what kind
of packet it is, but we're trying to subvert the original spec and come up
with new hacks by "peeking" into the payload and make assumptions about what
it is in order to rule or queue it differently.

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.

~~~
bogomipz
Ethernet has always "cared" what type of upper payload its carrying. It has
to, there are any other things besides IP that run directly on top of Ethernet
frames. For instance 0x0800 means that the ethernet frame is carrying an IPv4
datagram.

Here is a list of all the ethertypes it cares about:
[http://www.networksorcery.com/enp/Protocol/802/ethertypes.ht...](http://www.networksorcery.com/enp/Protocol/802/ethertypes.htm)

Fire up wireshark and you will see these.

~~~
colanderman
What the GP means is that layer 2 switches should forward traffic agnostic of
what the Ethertype field says. That field only exists so layer 3 knows what
it's dealing with.

~~~
bogomipz
I see. I misunderstood then.

------
ChuckMcM
Wow it blows my mind. Both that a switch _might_ have issues forwarding
packets with a perfectly valid MAC, and that there are so many MAC squatters
out there that the IEEE felt this was a good strategy. I guess its going to
get harder to use MACs like CA:FE:00:C0:FF:EE to easily spot your packets
coming from your home grown FPGA ethernet MAC implementation :-)

~~~
akira2501
> CA:FE:00:C0:FF:EE

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.

[1]: [https://tools.ietf.org/html/bcp128](https://tools.ietf.org/html/bcp128)

------
linkregister
Can someone break this down for me? Are 4 and 6 previously reserved MAC
prefixes?

~~~
Macha
From what I gather the problem is basically:

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))
    

And similar to the problems with

    
    
        os.name.startswith('Windows 9')
    

type issues, now we reach the higher numbers, these systems have issues.

~~~
web007
Are these not at different OSI layers and should be handled correctly by
encapsulation?

~~~
wmf
To save space in the MPLS header, it doesn't specify what comes next. So
inside an MPLS packet may be Ethernet, IP, or something else and in many cases
the switch/router has no way of knowing what is inside the packet, but it
still wants to find the 5-tuple to generate ECMP entropy.

~~~
linkregister
I was not aware that MPLS provides for encapsulation of Layer 2 frames.

------
bogomipz
Wow that's some serious persistence to work a Cisco TAC case all the way up to
it becoming a documented bug. I feel for those network engineers. I can only
imagine how many hours they spent on the phone with TAC. I've been there, its
not fun.

------
tinus_hn
It's wonderful to see how bugs in network hardware are suddenly the problem of
the registration authority and they need to delay a few years more. How about
the vendors start fixing their bugs instead? And if you have hardware and
there will be no fix, consider that the next time your going to spend your
money on hardware.

