Hacker News Reader

Comment by linkregister | Hacker News Reader

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

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.

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

They are, but these routers are doing inspection, even when they should be purely Layer 2, and then doing it stupidly, and then breaking.

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.

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

No, but it does sound suspiciously like it's related to 'IPv4' and 'IPv6'.

No, but datalink stacks have acted like they are for decades, and it's finally catching up with them.

I guess someone calculated that given current rate of sequential assignment of MAC ranges, we won't get to 4 and 6 prefixes in a very long time.

That reasoning was broken as it assumed sequential assignment is the only way to go.

Until fairly recently (in IEEE/OUI terms, ~2012), the distribution has been entirely sequential. FTA:

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

Nonetheless it was a broken parse: they needed to expend the memory to figure out what the actual protocol is and not jump up from the datalink layer if it's not called for. I guess I'm just saying I really can't blame IEEE here.

Oh, I don't blame the IEEE wholly - but I think that they probably changed tack after realizing that a number of manufacturers were simply not paying the fees to actually be assigned a block of OUIs. I view it as kind of a cudgel to be used against vendors, and end-users (read: netops/sysops) are caught in the middle.

Reply on news.ycombinator.com