Both IPs and MACs can be changed by the administrators and both can be set such that duplicates exist in the network. However the fact that MACs are set by manufacturer makes them impossible to route as the values are not related to the network locations but related to hardware origin.

Edit: As one of the replies stated, they are also used in Stateless autoconfig in IPV6 (see: https://en.wikipedia.org/wiki/IPv6_address#Modified_EUI-64)

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.

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.

And it well could be, but guaranteeing uniqueness is rarely as easy of a problem as you might wish.