I cannot understand please explain it!!
- If a PC wants to send to another PC through a switch and does not know its MAC address, that means all PCs on network will receive it and see it!!
Hosts on a LAN with a protocol that uses MAC addresses, e.g. ethernet, maintain an ARP table. A host on such a broadcast domain may eventually learn all the MAC addresses of the other hosts on the LAN in its ARP table, but the entries in the ARP table probably do time out after a while.
- If we change the NIC for a PC in the network, how will the other PCs know?
This is a problem that is discussed at the end of RFC 826, An Ethernet Address Resolution Protocol -- or -- Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware in the section title, "Related issue" (see below). Normally, a MAC address in an ARP table will eventually time out, or a host with a new NIC can perform a gratuitous ARP to inform all the other hosts of its new MAC address.
- In a flood MAC address table attack, why does the PC still sends frames, although it doesn't know the MAC address for a destination?
A host cannot send a frame unless it knows, or thinks it knows, the MAC address of the destination. It will use ARP to get a MAC address for the destination. Your question is more about the switch, and if a switch doesn't know the interface to which it should send frames for a MAC address, it will flood the frames to all other switch interfaces, and the host with that MAC address will get the frames destined to it.
Related issue:
It may be desirable to have table aging and/or timeouts. The implementation of these is outside the scope of this protocol. Here is a more detailed description (thanks to MOON@SCRC@MIT-MC).
If a host moves, any connections initiated by that host will work, assuming its own address resolution table is cleared when it moves. However, connections initiated to it by other hosts will have no particular reason to know to discard their old address. However, 48.bit Ethernet addresses are supposed to be unique and fixed for all time, so they shouldn't change. A host could "move" if a host name (and address in some other protocol) were reassigned to a different physical piece of hardware. Also, as we know from experience, there is always the danger of incorrect routing information accidentally getting transmitted through hardware or software error; it should not be allowed to persist forever. Perhaps failure to initiate a connection should inform the Address Resolution module to delete the information on the basis that the host is not reachable, possibly because it is down or the old translation is no longer valid. Or perhaps receiving of a packet from a host should reset a timeout in the address resolution entry used for transmitting packets to that host; if no packets are received from a host for a suitable length of time, the address resolution entry is forgotten. This may cause extra overhead to scan the table for each incoming packet. Perhaps a hash or index can make this faster.
The suggested algorithm for receiving address resolution packets tries to lessen the time it takes for recovery if a host does move. Recall that if the <protocol type, sender protocol address> is already in the translation table, then the sender hardware address supersedes the existing entry. Therefore, on a perfect Ethernet where a broadcast REQUEST reaches all stations on the cable, each station will be get the new hardware address.
Another alternative is to have a daemon perform the timeouts. After a suitable time, the daemon considers removing an entry. It first sends (with a small number of retransmissions if needed) an address resolution packet with opcode REQUEST directly to the Ethernet address in the table. If a REPLY is not seen in a short amount of time, the entry is deleted. The request is sent directly so as not to bother every station on the Ethernet. Just forgetting entries will likely cause useful information to be forgotten, which must be regained.
Since hosts don't transmit information about anyone other than themselves, rebooting a host will cause its address mapping table to be up to date. Bad information can't persist forever by being passed around from machine to machine; the only bad information that can exist is in a machine that doesn't know that some other machine has changed its 48.bit Ethernet address. Perhaps manually resetting (or clearing) the address mapping table will suffice.
This issue clearly needs more thought if it is believed to be important. It is caused by any address resolution-like protocol.
