An ethernet frame header is defined as:
struct ethernet_header {
uint8_t dest_address[6];
uint8_t source_address[6];
uint16_t length_or_ethertype;
};
My understanding is that the 6-octet MAC address format is now formally known as EUI-48. I have also read that there is another format, known as EUI-64, which describes an 8-octet MAC address.
But I'm very confused about the purpose of EUI-64. At face value, the obvious reason for EUI-64 is to deal with address exhaustion when we have more than 2^48 unique devices on Earth. However, all available information I can find Googling about EUI-64 seems to only talk about it in relation to IPv6. That is, EUI-64 provides a way to map a 48-bit MAC address to a IPv6 address.
But, apart from IPv6, does EUI-64 have any other purpose? Was EUI-64 invented purely to solve a problem related to IPv6, or was it also invented to deal with the eventual exhaustion of 48-bit MAC addresses?
I assumed that EUI-64 was primarily designed to deal with eventual exhaustion of 48-bit MAC addresses - meaning that many new hardware devices will be created that have 64-bit MAC addresses (or Extended Unique Identifiers, to use the formally correct term.) But if this is the case, how will any existing networking equipment, such as routers and switches, be able to tell the difference between a packet with a 48-bit source and destination address, and a packet with a 64-bit source and destination address?
Since the first two fields of an Ethernet header are the 2 48-bit source/destination addresses, we can't just replace these fields with 64-bit source/destination addresses, because any software inspecting the packet won't know how to tell the difference, since there is no "type" or "version" field that precedes the addresses. (In the way that, for example, an IP header conveniently has a 4-bit version field as the first 4-bits of the header, so we can easily distinguish between IPv4 and IPv6).
So my question(s):
Is EUI-64 meant to solve 48-bit MAC address exhaustion, or is it
only meant to map MAC addresses to IPv6 addresses?
If EUI-64 is meant to solve eventual 48-bit address exhaustion, how
can networking software distinguish between Ethernet packets
containing 48-bit versus 64-bit MAC addresses?
Since EUI-48 is allocated in 24-bit OUI chunks the address space is running low. Still, it is and will continue to be used for the very popular Ethernet and WiFi networks.
EUI-64 is a superset of EUI-48 and is intended for "new" applications. Currently, it's used for Firewire, ZigBee and, in a EUI-48-derived form, for IPv6.
Related
I am sorry if its basics, but I did not find the appealing answer for it over the Internet.
Why only MAC is used to transfer the packet to a device ? MAC address is only obtained by ARP for a specific IP address. So, why not just let the routers maintain IP addresses of the neighbouring routers and route packets using IP addresses of routers instead of MAC addresses ?
Why not redesign the architecture, to only use IP address for routing as well as moving the packet in the data link layer too ?
Why do we need MAC addresses?" Why can't network devices such as the routers just send the packet to the next router using the router's IP address?
Note : I know that MAC address is used to identify the system in a network. But you see the source never knew the MAC address of receiver. All it knew was its IP address and MAC address of next hop.
I'm reading Data Comm and Networking by Forouzan ( Ed 5) and it says that even routers have an IP address. So why use the mac address at all. The router can store the IP address of the source and route it to the next router .
EDIT : The question that I was getting as suggestion to this one does not answer my query. There are multiple counter points and proof that I have presented here which could have been done which is not answered by the one which is suggested. So please read my question before making any assumptions.
What do you think makes more sense: Having one protocol like Ethernet handle all the layer 2 details so that its layer 3 payload doesn't have to care, or force IP, ARP, WoL, IPX, MPLS, SLPP, and dozens more implement it on their own? The whole purpose of OSI layers is that upper layers need not know all the lower layer's details and lower layers need need not support the upper layer's features.
MAC addresses are used for the layer 2 protocol which encapsulates a layer 3 protocol. If all the necessary features were embedded into IP, then you'd be leaving other protocols to re-implement layer 2 routing on their own. This would be wildly inefficient.
I understand that it's different than a hub in that instead of packets being broadcasted to all devices connected to the device, it knows exactly who requested the packet by looking at the MAC layer.
However, is it still possible to use a packet sniffer like Wireshark to intercept packets meant for other users of the switch? Or is this only a problem with ethernet hubs that doesn't affect switches due to the nature of how a switch works?
On a slightly off topic side note, what exactly is classified as a LAN? For example, imagine two separate ethernet switches are hooked up to a router. Would each switch be considered a separate LAN? What is the significance of having multiple LAN's within the same network?
it knows exactly who requested the packet by looking at the MAC layer.
More exactly, the switch uses the MAC destination address to forward a frame to the port associated with that address. Addresses are automatically learned by looking at the MAC source address on received frames.
A switch is stateless, ie. is has no memory who requested which data. A layer-2 switch also has no understanding of IP packets, addresses or protocols. All a basic switch does is learn source addresses and forward by destination address.
is it still possible to use a packet sniffer like Wireshark to intercept packets meant for other users of the switch?
Yes. You'll need a managed switch supporting port mirroring or SPANning. This doesn't intercept frames, it just copies them to the mirror port. If you need to actually intercept frames you have to put your interceptor in between the nodes (physically or logically).
With a repeater hub, every bit is repeated to every node in the collision domain, making monitoring effortless.
what exactly is classified as a LAN?
This depends on who you ask and on the context. A LAN can be a layer-1 segment/bus aka collision domain (obsolete), a layer-2 segment (broadcast domain), a layer-3 subnet (mostly identical with an L2 segment) or a complete local network installation (when contrasted with SAN or WAN).
Adding to #Zac67:
Regarding this question:
is it still possible to use a packet sniffer like Wireshark to
intercept packets meant for other users of the switch?
There are also active ways in which you can trick the Switch into sending you data that is meant for other machines. By exploiting the Switch's mechanism, one can send a frame with a spoofed source MAC, and then the Switch will transfer frames destined to this MAC - to the sender's port (until someone else sends a frame with that MAC address).
This video discusses this in detail:
https://www.youtube.com/watch?v=YVcBShtWFmo&list=PL9lx0DXCC4BMS7dB7vsrKI5wzFyVIk2Kg&index=18
In general, I recommend the following video that explains this in detail and in a visual way:
https://www.youtube.com/watch?v=Youk8eUjkgQ&list=PL9lx0DXCC4BMS7dB7vsrKI5wzFyVIk2Kg&index=17
what exactly is classified as a LAN?
So indeed this is one of the least-well-defined terms in Computer Networks. With regards to the Data Link Layer, a LAN can be defined as a segment, that is - a broadcast domain. In this case, two devices are regarded as part of the same segment iff they are one hop away from one another - that is, they can switch frames in the second layer.
Pardon my limited knowledge in networks.
I am trying to setup two small programs as client and server, which join to a particular multicast group. The servers sends some arbitrary data to the group and the client receives the data as it listens to the group.
This of course is possible with UDP programs which I have already done. However I need to work with MAC addresses instead of IPs. And I have a few questions regarding this:
Is it possible to fix a range of MAC addresses for my multicast application ? As I understand, the least significant bit of the first octet in the MAC address signifies if it is multicast or not. So the multicast MAC should look like 01:*:*:*:*:* . So I guess, there should be some way to use a wide range of MAC addresses (except for those reserved).
Many places it is written as All multicast MAC addresses begin with: 0100.5e . Is it always true? AFAIK this prefix is fixed in the MAC address which leaves space for the rest of the IP address bits to be mapped here. But what if my application doesn't care about IP addresses and listens to multicast groups based on MAC addresses (if it is possible) ?.
Can't I keep the first octet as 01 and use a wide range for my multicast addressing ?
How to send packets to a multicast group and listen to a multicast group only based on MAC addresses and irrespective of IP ? i.e. the multicast group addresses are defined based on MACs.
I hope my questions made sense.
If you are not using IP (or UDP on top of that) then the default way of mapping IP addresses to mac addresses have probably no added value for you. These mappings are specified for example in:
http://en.wikipedia.org/wiki/IP_multicast#Layer_2_delivery
rfc1112 https://www.rfc-editor.org/rfc/rfc1112 paragraph 6.4
If you insist on using layer2 and multicasting it will probably be sufficient to send out frames with the LSB of the first octet set (the multicast bit, ref: http://en.wikipedia.org/wiki/File:MAC-48_Address.svg ). And put your own mapping on top of that. But you should take into account that:
you probably need to force your NIC to pass the data, often NIC's filter out frames they are interested in hardware. And these filters are typically set when joining a group or e.g. when setting the ALLMULTI flag).
There is probably networking equipment in the middle and some pseudo-intelligent switches may refuse to forward data unless they have seen IGMP joins (ref igmp snooping).
And you code will obviously need to deal with raw layer 2 sockets to read out the data.
Considering the ease of just using UDP this may be a lot of work.
Usually, a switch can populate its MAC address table automatically by
learning the source MAC addresses of incoming frames on each port.
I found the above sentence in the following reference:
04-Layer 2 - LAN Switching Configuration Guide
Why doesn't a switch use the destination MAC address of outgoing frames for MAC learning?
I think it's useful for preventing flooding in some situation which I have.
Why doesn't a switch use the destination MAC addresses of outgoing frames for MAC learning.
Short answer: Because it's pointless to learn from destination mac-addresses
Long answer:
A switch learns two things from the source mac-address when an ethernet frame is sent:
The value of the mac-address of the ethernet NIC attached that that cable
The number of the port which has the aforementioned mac-address
Destination mac-addresses don't provide useful information for a switch to learn from. When a PC sends an ethernet frame somewhere, the switch must deliver to that destination mac-address. Learning a mac-addresses' existence and location coincidental to the delivery event is a broken algorithm.
Why do we need an IP address when the MAC address is unique? Cant we communicate only with the MAC address?
You COULD communicate using only the MAC address, but only on your local network. IP addresses are routeable, without every system on the network needing to know about every other. You just need to know a range of addresses that are on your local network, and throw everything else up to your router. The same thing happens at the ISP level. "All 216.x.x.x traffic goes that way, all 105.x.x.x goes that way..."(Obviously a gross oversimplification, but that's the basic process).
If we tried to route everything by MAC address, every machine on the network would have to maintain a list of every other participant, and it just wouldn't scale.
No. MAC addresses are specific to Ethernet, IP is independent of the underlying hardware. You can connect machines that don't use Ethernet to the Internet, if you have the required bridges.
MAC addresses are not unique. MAC addresses are reused between media. This is why wireless (802.11) and wired (802.3) may not both be present on one collision domain (see 802.1D).
MAC addresses are not clustered -- meaning that devices which are nearby in network space do not have nearby MAC addresses. IP addresses do have this property of locality. Do you intend to route packets by having a universal list of MAC addresses copied to every computer on the Internet, or do you intend to route packets to their destinations through a hierarchy of localities?
On a single collision domain, MAC addresses can be the primary addressing mode (q.v. arp and rarp). However, extension to multiple collision domains is ineffective for the above reasons.
A great professor of mine named George Varghese, now at UCSD, made the following apt analogy: You want to send someone a letter. The analogy of sending to a device anywhere in the USA based on its MAC address is like sending someone a letter knowing only their Social Security Number. It does uniquely identify someone (OK, yes, SSN isn't guaranteed unique, but suppose it was for the sake of example), but it would be very hard to find them without some giant table of where everyone lived that you could look up indexed by their SSN.
An IP address (and the similar Open Systems Interconnect, or OSI, network addresses) are more like USA phone numbers with area codes and exchange numbers: (AAA) BBB-CCCC, where AAA is an area code, BBB is an exchange number, and CCCC identifies an individual line at that exchange. There is hierarchical information encoded in that number, so that when you are far away from the destination, you only need a small table indexed by area code to determine a good "next hop" to forward the call to, rather than a table of all phone numbers in the country.
Ethernet is a Medium Access Layer protocol. It was designed specifically to connect computers on the same network. If you want to connect computers remotely located, you certainly need to jump to destination by hopping through several routers. IP (Internet Protocol) was designed with this goal in mind, hence the need for it, while Ethernet protocol does not support routing. Only some forms of primitive bridging that would not scale for something huge like the Internet.
they are used for different protocol layer.
MAC address is your device specific address. It has no relation with the geographical location, etc. you are in currently.
Ex: You can buy a cellphone/laptop in US and use it in Japan,
Australia, etc. But MAC address would remain the same. But IP address
would change with respect to the network you are connected to.
So it is difficult to route packet in an internetwork of portable devices especially.
How would it be:
Consider you have a portable network-accessing device with you on which you are using the internet. If we use only the MAC address, how would any incoming packet find the location of your portable-device. Since MAC address gives you only a fixed 48-bit device address. (The worst case scenario is using a desktop computer and having a MAC address without the IP facility. Coupling it with the static table to find your predefined location based on the MAC address, but our life is incomplete without these portable devices right?)
Thus we need some addressing scheme that can help us with addressing in a big and portable environment like internet, and thus the role of IP comes into picture, where address is hierarchal to provide a more geographically exact location.