
Why couldn't MAC addresses be used instead of IPv4|6 for networking? - pooriaazimi
http://serverfault.com/questions/410626/why-couldnt-mac-addresses-be-used-instead-of-ipv46-for-networking
======
trout
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 same IP address at all times, which means you can be
tracked to where that devices is and has been based on the routing rules.

As well, ethernet is not IP. They are different layers of the OSI model. Just
because you're on ethernet (wired/wireless) doesn't mean you're using IP, and
vice versa. Some devices don't have MAC addresses. Frame relay uses DLCI's for
instance. Historically there were lots of other technologies using IP that
weren't ethernet - FDDI, token ring, ATM, etc. Ethernet has replaced nearly
all of those, but not all.

Routing scalability - another huge problem. But this will rear it's head in
IPv6 with the exponentially large amount of possible routes. Right now the
routing tables are around 350k-400k routes. Compare that to the billions of
devices that connect to the internet simultaneously.

MAC addresses are locally assigned addresses. There would be no way to prevent
duplicates. In most networks, your IP address will specify the way you are
routed through the network and your security level. If that isn't centrally
managed you have no security or IP addressing schemes.

[1] <http://tools.ietf.org/html/rfc4941>

~~~
bdb
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...)

------
AUmrysh
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 numerous devices will share the same MAC address, it's
just statistically unlikely to find them on the same network. It's an
especially big problem with cheap/knockoff network equipment. See:
[http://www.linuxquestions.org/questions/linux-
networking-3/m...](http://www.linuxquestions.org/questions/linux-
networking-3/multiple-nics-with-the-same-mac-address-930357/)

~~~
derleth
> If all addresses were based on mac, you could easily intercept the messages
> from anyone.

So you encrypt stuff you don't want anyone else to read. Security isn't the
concern of the networking layers; it's all done, to the extent it is done, at
the application layer.

That's the original design, anyway.

Edited to add: Well, the _original_ original designs were by people who
weren't thinking of security at all. That's why telnet and FTP are the way
they are.

> Another problem is that numerous devices will share the same MAC address,
> it's just statistically unlikely to find them on the same network.

This, on the other hand, really is a perversion of the intended model. 48 bits
was intended to be globally unique.

~~~
mburns
>it's all done, to the extent it is done, at the application layer.

Sometimes true but often not. Encryption can and does happen at various layers
of the (OSI) networking stack (Secure Session Layer, Transport Layer Security,
Internet Protocol Security).

>That's why telnet and FTP are the way they are.

Those programs are the way they are due to a holdover from the Unix
philosophy: do one thing and do it well. Sure, functioning _at all_ was more
important than functioning securely. If you ran your connections over a VPN,
SSL or IPSec line, the fact that telnet didn't _also_ support encryption would
be moot.

The Application layer is for the applications data. If you want to secure the
transmission of that data, it shouldn't be up to each and every individual
application to support encryption.

This is why things like IPv6 or SPDY/HTTP2 have baked-in encryption below the
application layer.

------
inopinatus
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 physical.

(Note: it remains a common - indeed, conventional - configuration & design
error to bind an IP address to an interface. There is no such requirement and
this complicates many networks. I was irritated to learn that IPv6 makes use
of the MAC address in self-autoconfiguration)

(ObAuthority: I used to make ISP management systems for a living)

~~~
est
> An IP address identifies a host, whilst a MAC address identifies an
> interface.

... while a MAC can host multiple IP addresses (see vmware bridged network for
guest OS), and the same interface can have multiple MAC addresses. And a
devince can have multiple real/virtual interfaces.

------
cwb71
I do not understand why this story is being upvoted. Are we supposed to
duplicate the answers on serverfault here (which seems to be most of the
comments) or are we making fun of the question or what?

------
0x0
Routing packets based on MACs would be impossible. That's why.

My laptop has the same MAC whether it is connected at home, at work, or in the
airport. How would ISPs and the internet backbone routers know where to send
the packets to reach me?

~~~
sneak
Thank you for summarizing the answer in the linked article.

You may now proceed to posting solutions to FizzBuzz in Jeff Atwood's blog.

~~~
0x0
Well, what kind of discussion would you expect for an article like this?

Perhaps you should spend your time revising your HN bio instead.

------
hapless
No reason at all. Novell Netware did _exactly this_.

The host portion of your address was your MAC. Networks were identified by
their local netware servers.

~~~
astrodust
This is one of the reasons why IPX was a bad idea and never took off.
Automagical discovery is always great until it doesn't work.

~~~
bdunbar
_and never took off._

IPX was everywhere NetWare was.

NetWare got into everything, like dust, in the 80s and part of the 90s.

~~~
astrodust
Being _prevalent_ , which it no doubt was, and being _pervasive_ are two
different things.

IP has a way of worming itself into every little thing. IPX never really
escaped from the desktop network environment.

~~~
bdunbar
I did not know that pervasive was synonym for 'took off'.

------
yskchu
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.

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

~~~
inopinatus
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.

------
iioowwee
They already are. Part of the IPv6 address is derived from your MAC.

Despite not owning the network for which they are being allocated, IPv4 is a
"paying job" to some people. And sometimes an ego boost too, i.e., people who
get their kicks from creating "IP address policy". Needless to say this easy
"work." Hello ARIN.

It's a lot like ICANN.

On CircleID someone recently pointed out that IPv6 will make this sort of
"job" meaningless. There is so much IPv6 address space that playing favorites
and charging hefty fees is unjustifiable.

Back to your point about MAC's: This is also why the "we're out of IP
addresses" meme seems silly. Because we don't see the IEEE complaining they
are "running out of MAC's". And IPv6 addresses use MAC's.

The thing to keep in mind is that just because something, e.g. a better
addressing scheme, or true network-level peer-to-peer networking, is not
"widely adopted" does not mean it isn't available, _right now_. It may have
been available for years. There were people at universities still teaching the
use of punch cards even after a well-known computer professional in Canada was
already programming using a terminal display. And there were other Canadians
sending emails before DARPA.

Do not assume that the crowd is always wise. And be wary of the "hype".

80/20 rules - another great internet meme - mean than we can have 80% of the
people being stupid. And the 20% have to suffer.

When the "new" naming, "new" addressing and "new" peer-to-peer solutions are
offered up the next time, keep an open mind. Try not to be so quick to dismiss
any sort of change to the "status quo". Evaluate the approach carefully. It
might have merit, and maybe it's not immediately obvious.

Many times (in fact almost all the time), the solutions are not new. We're
just waiting for people to finally catch on and realize there is "a better
way". We're waiting for people to "try something 'new'".

~~~
regularfry
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 IP address.

> On CircleID someone recently pointed out that IPv6 will make this sort of
> "job" meaningless.

Er... not sure how that follows. If routing tables aren't going to grow
without bound, there's no less need for central allocation authorities than
there is with IPv4. The important job isn't rationing, it's keeping allocation
as contiguous as possible so the network hardware can keep up.

> Back to your point about MAC's: This is also why the "we're out of IP
> addresses" meme seems silly. Because we don't see the IEEE complaining they
> are "running out of MAC's". And IPv6 addresses use MAC's.

Not quite sure what you're getting at here. When people say "we're out of IP
addresses", they're talking about IPv4 addresses. That's not silly at all -
it's real, it's happening now, and IPv6 _still_ hasn't quite got the
penetration to get us out of the hole yet.

The rest of your post would be more useful with some specifics.

~~~
iioowwee
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 some sort of authority to make sure people are not using the same
addresses.

Nodes need a way to find each other. Routing tables are simple enough and they
work. I will leave that alone.

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.

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.

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.

There are easy ways for nodes, with crusty old IPv4 addresses, to get through
their crusty old NATs and get open UDP ports to communicate with each other.
They are not new. And they work. Gamers have been using stuff like this for
decades. But there's a lot more utility to being directly connected than just
playing games. Enter Skype.

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.

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.

Personally I never understood the lure of connecting to a "swarm" via some
DHT. And this is the thinking that has pervaded peer-to-peer. The concept of
connecting to strangers, something like Chatroulette, is not really
interesting from my perspective. But a lot of technically capable people think
that sort of thing is worth their time.

I want to connect to my friends and family, not random strangers. I want to
use the internet for all the things it's been cracked up to be for so long: a
replacement for postal mail, telephone, video conferencing, etc. And I do not
think I am alone in this view.

It's not a new idea what I'm getting at: breaking things into smaller pieces
to manage them. What is the internet after all but a conglomeration of ASN's
-- smaller networks.

"BOOTP for the global internet." A way to find each other. And then a way to
connect. Opensupernodes. The rest, what you do after connecting, is up to you.
That's _your_ network, not Facebook's, Google's, Microsoft/Skype's or anyone
else's.

Cooperation, interoperability, (at least ostensible) simplicity. People's
comfort with working and playing in small groups. These are the important
points in my mind.

~~~
regularfry
> 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.

------
vacri
We need a public service announcement to show the differences, something along
the lines of "I'm a MAC, I'm an IP"

------
vdm
Interconnections: Bridges, Routers, Switches, and Internetworking Protocols
(2nd Edition) Radia Perlman <http://www.amazon.com/dp/0201634481/>

This book explains how conventions in data networking were established, how
words became used as the terms for particular obvious but slightly ambiguous
concepts, e.g. 'names' vs 'addresses', bridging vs routing. It also puts IP in
to context viz. other LAN protocols before it became dominant. Recommended.

