If my computer has an IP address,why does it need a MAC address?
without going into OSI model, TCP layer, etc.:
Back in time, networks were created: some computers would communicate with each other to share something. TO do that, they need to know who was talking and who was being talked to. So, instead of giving each computer a name, we gave them an ID. This ID is called MAC address, is should uniquely identity each computer.
(ok, identify each network card, but back that time, you could think one MAC address for each computer).
There wasn't a unique specification on how computers would talk to each other: many protocols appeared: TCP/IP, IPX/SPX, and so on. Each protocol would specify things as they thought was ok. For example, IPX/SPX would address each computer using the MAC address and some more information.
But the TCP/IP protocol was designed a little bit different: they decided that having an virtual address, made of 4 bytes (0.0.0.0 to 255.255.255.255) was enough, and was even easier to manage: it doesn't matter if your network cards all have a similar MAC address or not, we'll group our computer so that all TCP/IP address that began with 10.0.x.x. are part of the engineering group, and those of 10.1.x.x. are the printers, and...
So, if a TCP/IP address needs to comunicate with another, is just uses the TCP/IP address. But the network devices need to know to which network card that message is going, so they, somehow, translate the TCP/IP address with to the MAC address.
Why not simply eliminate the MAC and instead use just TCP/IP ?
- easy to group TCP/IP addresses,
- all devices are built to take care of the MAC address, in that low-level requirement, and would need to be changed
- despite being the vast majority (I think :-P ), some other protocols are still in use and they rely on the MAC address
MAC addresses and IP addresses operate on different layers of the internet protocol suite. MAC addresses are used to identify machines within the same broadcast network on layer 2, while IP addresses are used on layer 3 to identify machines throughout different networks.
Even if your computer has an IP address, it still needs a MAC address to find other machines on the same network (especially the router/gateway to the rest of the network/internet), since every layer is using underlying layers. On the page mentioned earlier you can find some nice diagrams explaining the protocol suite in detail.
When you understand that IP-to-IP communication is really just a series of MAC-to-MAC communication taking place at each router hop, then you'll see why both are necessary.
The IP header of a packet leaving your workstation destined to an IP in a different subnet will maintain the source IP and destination IP, forgetting about NAT for the moment. [Later, I will discuss what happens when the destination is within the same subnet.] The Ethernet header contains your source MAC and the destination MAC of your default gateway. There's no knowledge of the final destination MAC from your perspective. That first router will rewrite the source MAC to itself and the destination MAC to the next router hop, and so on, until the packet arrives at the last router that is directly connected to the destination subnet.
To attempt a simple illustration, consider the L2/L3 headers as a packet moves from the source IP (sIP) to a destination IP (dIP) and the source and destination MACs are rewritten along the way -- fs=first-source and ld=last-destination, and r1-r3 are routers:
fsMAC-r1MAC / sIP-dIP r1MAC-r2MAC / sIP-dIP r2MAC-r3MAC / sIP-dIP r3MAC-ldMAC / sIP-dIP
Any L2 switches involved will not modify the MAC addresses.
Now for communication to another IP within your subnet, direct MAC communication is needed, but to get that MAC addr requires the ARP protocol that uses a broadcast in the subnet to find it. By the way, this is how your workstation gets the MAC address of your default gateway that must exist in your same subnet.
There isn't anything physically stopping you from designing network which has just IP address for L2 and L3. Then 'ethernet switch' would learn SIP address of incoming packets and flood or forward towards DIP address.
However this network would only ever support IP, when next-generation of IPvX comes, it would not work, as the 'ethernet switch' couldn't support that protocol. You also couldn't run various other protocols, like IPX and AppleTalk, or some new protocol you're developing and testing in your home.
Abstraction layers increase development speed and encourage innovation, as you don't need to rebuild whole house to change a window.
Now you could have ran same ethernet switches and migrated your network in between from IPX to IPv4 to IPv6, without touching your LAN at all.
The IP address and MAC address serve different (but crucial) purposes:
The MAC address gets a frame from one NIC to the next. The IP address gets a packet from one Computer to the Server
So given the following:
Source Computer <---> RouterA <---> RouterB <---> Destination Server
What directs the packet to the from the "Source" to the "Destination" is the IP address. But what gets the packet from the Source Computer to RouterA, and then from RouterA to RouterB, and then from RouterB to Destination is the MAC addresses.
You can see the relationship in this illustration:
The IP protocol provides the foundation to support the notion of subnets and routing. This means IP doesn't assume your destination is in the same network - if it's not, your traffic needs to be forwarded through an intermediary device such as a router. IP has TTL/Hop Limit fields and such that support this.
Ethernet assumes that the destination MAC is directly reachable when data is shipped out of its interface. Ethernet was originally designed when the most common way to connect computers in a network was through a physical bus topology. Even though almost all wired Ethernet traffic is switched now, logically it still works like a bus topology. So the underlying assumption with Ethernet is that the node with the destination MAC is physically on the same network. There is no such assumption with IP.
I guess you could "hack" Ethernet into doing subnets and routing, but you might as well engineer a protocol that doesn't rely on the low level details and assumptions of Ethernet, and that's why we have IP.
To be as simple as possible:
A Mac Address is the physical or virtual address of your NIC card or network interface. From a computer on a network's standpoint, it is the physical address of that computer's NIC card. It is used to bring information to that computer on Layer 2 of the OSI model.
The IP address is required on layer 3. You require it to communicate with computers on different subnets and devices.The IP Address verifies "where" the device is located within a network.
The IP addresses and Mac Addresses are used in tandem. Address Resolution Protocol is used to link the two together by resolving IP Addresses to Mac Addresses within the Link Layer within a single network.
You might want to also check here for a more in-depth explanation.
MAC address represents the hardware ones its assembled it is constant and diffrent systems in our network made by diffrent vendors have very diiffrent range of mac addrees so that they are difficult to arrange as a network.but using ip addresss we can arrnge the devices in our network in arange that is simultaneous addresses.also we can not send our mac addrees to outside networks
To start with, this is a very good question, which touches upon the basic network foundations. The bottom line to your question is, we don't really need a MAC address in order to achieve connectivity. Theoretically, a network could be built implementing IP addresses alone! However, some practical difficulties may arise out of using such a scheme. If you expect to manually assign an IP address to each network device, then you may avoid the major pitfalls. However, if you need to automatically assign IP addresses, as when there are too many network nodes to manually administer, then there is no way to make sure each node is allocated exactly a single IP address, or a predetermined number of them, because you cannot tell one from the other, unless the address distribution entity can uniquely and unequivocally identify the requesting device, e.g. by its MAC address, which is assumed to be unique for any device in a LAN. Such an unidentifiable device may repeatedly ask for additional IP addresses and, eventually, wreak havoc on the network viability. Back to the topic, all you need to establish an IP-only network, is to let network interface adapter's Data Link Layer pass through any data frame it receives, directly to the Network Layer, regardless of any MAC comparable address type, where it can be filtered according to its destination IP address, instead of being filtered at the Data Layer. Just to illustrate the concept, assume a network is established by interconnecting RS-232 UART ports: UART devices don't have MAC addresses, or any other unique identifier, for that matter, yet you could construct a local network using UARTs and IP addresses alone, providing you install the proper UART drivers. Hope this passage gave you some insights on the subject.