Live data from Hacker News

Why couldn't MAC addresses be used instead of IPv4|6 for networking?

serverfault.com

31–38 of 38 posts

Re: Why couldn't MAC addresses be used instead of IPv4|6 for networking?

#31

None of the reasons given seem correct to me. Many of the reasons I see given are conventions arising from use and misuse. The simple answer is this: An IP address identifies a host, whilst a MAC address identifies an interface. That is all. Absolutely everything else, such as route aggregation, routing policy, and the behavioural differences between layers, stems from this primary distinction between logical and phy…

And if your NIC dies and needs to be replaced, imagine having to update all the other machines that referred to the old MAC.

Re: Why couldn't MAC addresses be used instead of IPv4|6 for networking?

#32
post #17

"Why don't we use social security numbers to deliver mail"

Well, although that's a nice metaphor for the answer, in practice I can imagine that using a personally unique ID for physical mail routing is quite possible. A billion or so rows in a database that links an ID number to spatial coordinates is perfectly conceivable, it'd only be in the tens of gigabytes. It'd also aid in redeliveries and redirections. There would be no reason to even keep this unique, one could have many such numbers to avoid correlations.

Using the SSN itself, of course, has vast privacy & security complications.

Why doesn't this work for IP? Because on that scale, the route table is too large to advertise and too large to keep in the working memory of current router linecard ASICs for sub-microsecond lookup, speeds a postal service does not aspire to.

Re: Why couldn't MAC addresses be used instead of IPv4|6 for networking?

#33
Noone seems to have hit the nail on the head yet, the reason's quite simple.

Routing.

Let's say you have an IP of 202.20.10.5 and you live in New York.

Your ISP allocated 202.20.10.x to New York

Your ISP owns 202.20.0.0, and advertises this over BGP

When someone tries to reach you, they first lookup: 202.20.0.0/16, the closest match.

Then then know to send the packet to your ISP, who sends it to 202.20.10.0/24 (New York), who then routes it to you.

How about if we use mac addresses? So let's say your mac address is: EW:34:AO:QW:RE:80

How would someone be able to find you? If they needed to do that, then:

1) Your ISP will need to advertise EW:34:AO:QW:RE:80

2) They send the IP packet to your ISP, who routes it to you.

If the ISP has 1 million customers, then it'll have to advertise 1 million MAC addresses in its lookup table...

Instead of just 202.20.0.0/16 (one entry)

It's not scalable to use MAC addresses for Internet use.

On the other hand, if you're talking about a local LAN, then yes, MAC addresses are used, and is actually already being used, for networking.

Re: Why couldn't MAC addresses be used instead of IPv4|6 for networking?

#34
post #2

Typically, MAC is assigned by the hardware manufacturer (sometimes you can change/spoof it). IP is typically assigned either by the network administratior or DHCP. If all addresses were based on mac, you could easily intercept the messages from anyone. IP allows a layer of abstraction in which you can group multiple subnets into the same external IP or set up subnets within those subnets even. Another problem is that…

MAC and IP are in two different layers of OSI model and while both are technically addresses, they are independent of each other and their role is different. Not every network uses IP addressing and not every device has a MAC address.

Re: Why couldn't MAC addresses be used instead of IPv4|6 for networking?

#35
post #7

Lots of reasons. From a security perspective - IPv6 SLAAC (sort of like DHCP) does this - it uses the MAC as the last 48 bits of the 128 bit address. However, this is largely seen as a security problem things like RFC 4941 [1] have argued against this idea. If you think having your iPhone keep a track of which cell phone towers you've been to is bad, think about the consequences of being globally reachable by the sam…

It'll certainly be interesting to see if scalability of the IPv6 DFZ routing table is actually better or worse than that of v4 (adjusted for growth in number of multihomed organizations, of course.) One could make an argument that the bloat in the v4 table today is largely due to disaggregated allocations from the RIRs due to exhaustion-avoidance address space allocation policy.

It is entirely possible that large organizations will be able to advertise fewer prefixes, as they have large, contiguous allocations, and thus can more efficiently aggregate at the border.

(Sorry, this is a bit late, but your comment got me to thinking...)

Re: Why couldn't MAC addresses be used instead of IPv4|6 for networking?

#36
I personally think that regardless of how it would be done, having a hardware specified ID for a user is a good idea. MAC wouldn't be the right thing to use, but something programmable similar to the ID on a SIM card. If done years ago, it would have solved a myriad of ID-related issues we've had since. Computers would not be interchangeable tools that employers can buy for you, but rather they would be more of an extension of ourselves that we could carry around with us.

Google wouldn't have provided 2 factor auth if OpenID were sufficient. 2 factor auth requires a mobile phone which is assumed to be on the user's person at almost any time. Hmm... that sounds like the scenario I was talking about where the device is an extension of yourself and is associated with something that is your personal ID- your phone#, and not some transient IP address.

P.S.: Reading the serverfault comments under one of the answers made me want to have enough rep to downvote Chopper3. That guy had some asinine remarks which I've never seen before on any of the fogcreek sites, and despite his 60k rep should be docked down to 0 for that.

Re: Why couldn't MAC addresses be used instead of IPv4|6 for networking?

#37
post #24

Earlier quoted context omitted.

No. An IPv6 address can be partially derived from a MAC, but a lot of the time it won't be. For instance, none of the VMs we operate (which all have an IPv6 /64 assigned) have real network hardware, so it makes no sense to generate the IPv6 address from a MAC there. And you can still multihome a single IPv6 address across more than one physical interface, so again, that's not somewhere you'd want to put a MAC into an…

For instance, none of the VMs we operate (which all have an IPv6 /64 assigned) have real network hardware, so it makes no sense to generate the IPv6 address from a MAC there. But each vNIC does have a subnet-unique MAC address, right? Why not use it? And you can still multihome a single IPv6 address across more than one physical interface, so again, that's not somewhere you'd want to put a MAC into an IP address. As…

> But each vNIC does have a subnet-unique MAC address, right? Why not use it?

Why use it at all? If it's not related to a real, physical item (and maybe you don't make any guarantees about MAC uniqueness across VM clusters), it's pointless bureaucracy.

> As long as you break the tie deterministically, I don't see the harm in picking one of the interface MACs.

Again, why would you bother to do this? If you've picked one of the NICs as "blessed", you're one hardware replacement (or network reconfiguration) from neither being blessed - so why not just assign in sequence from whatever netblock you're dealing with to start off with, and ignore the hardware?

Re: Why couldn't MAC addresses be used instead of IPv4|6 for networking?

#38

Earlier quoted context omitted.

No. An IPv6 address can be partially derived from a MAC, but a lot of the time it won't be. For instance, none of the VMs we operate (which all have an IPv6 /64 assigned) have real network hardware, so it makes no sense to generate the IPv6 address from a MAC there. And you can still multihome a single IPv6 address across more than one physical interface, so again, that's not somewhere you'd want to put a MAC into an…

The rest of your post would be more useful with some specifics. I translate this as: "I don't know how to make a solution. Please tell me how." Which is often followed by "It won't work." As for VM's, it's true what you say. But at some point if you are connecting to a global network (internet), there is a physical machine that has to connect. And that machine needs an address which cannot be "faked up". Indeed, you…

> I translate this as: "I don't know how to make a solution. Please tell me how."

That would be a mistranslation. Try "I can't tell what you're referring to, or if you know what you're talking about." We already have a solution to running out of IP space - it's called IPv6.

> As for VM's, it's true what you say. But at some point if you are connecting to a global network (internet), there is a physical machine that has to connect. And that machine needs an address which cannot be "faked up". Indeed, you some sort of authority to make sure people are not using the same addresses.

The IP addresses for the VMs can't be "faked up" either. They need to be publicly visible.

> But people have come up with all sorts of complicated schemes to try to allow nodes to find each other in a decentralized way, namely DHT type stuff and progeny of DHT type thinking.

DHT is irrelevant.

> But who says you have to mess with (replace) the existing infrastructure? Maybe you can just build on top of it. Maybe the exiting infrastructure is a bootstrap. The buzzword is overlay. Old hat, right? Well, almost nothing is truly new. And still, the overlay approaches people know about are often mindlessly complicated. We can do better. Some have done better.

Ok, this is where some specifics would be useful. What "better" approaches have you got in mind?

> NAT doesn't try to replace the existing framework. It just deals with it.

> It isn't pretty, but this is how we are all connecting, in spite of all the IPv4 policy nonsense. NAT solved a problem. (And created a new one, arguably.) Whatever. It works.

Except when it doesn't. That's the point. NAT is just broken for a lot of use cases.

> Once that's done, once we're connected directly, we can forget about overblown global routing tables, brittle BGP, DHT and IPv6 dreaming. We can use plain ole Ethernet, we can keep our own small arp and IP routing tables, we can use private address space (or whatever numbers we want - it's our private network) and MAC's. We can run our own DNS. We can keep things simple and secure. Because we can have small private networks. We can manage them ourselves.

s/can/have to/g. Sure, you can "solve" the problem by balkanising everything. Most people would regard that as a huge step backwards, to be avoided at all costs.

> The global network was means to an end: finding each other and conecting directly. It was a bootstrap. If it runs on crusty ole IPv4 and depends on NAT and swollen routing tables, so be it. That's not my network. It is just a means to an end.

So you'd foist complexity on the rest of the world because your use cases don't match everyone else's? Nice. You say you want simplicity? Ethernet-over-UDP between asymmetrically NATted private networks, relying on some unspecified entity resolution protocol and UDP hole-punching, is precisely the opposite. It comes with the added bonus that you've made establishing a connection in the first place ludicrously expensive. You're arguing against a bigger, global network which supports all the use cases you're talking about and fixes the problems we're running into with IPv4, in favour of a hideously inefficient scheme which breaks things people want to do today.

> I want to connect to my friends and family, not random strangers.

And yet here you are, communicating with a random stranger on a random website, which is only possible right now because of a flat global public IP space.

Post reply on HN