Thomas,
Any ethernet packet sent out that is less than 64 bytes should be "padded" by the driver or higher level protocols to that size. Padding is additional, non-meaninful data that is discarded. Usually, because there can be a checksum over the whole packet, zeros are the padding of choice.
Ethernet requires this minimum size to ensure that a collision is detected reliably. As you probably know, ethernet is really a serial media, in this case meaning that one (encoded) bit at a time is sent out on the wire. So the sixty four bytes take a definite "length of time" to transmit.
Moreover, the collision detection only occurs within this first 64 bytes. This size and collision-detection mechanism are tied to the physical size of the network - by size, I mean, how long the cable runs are. Excessively long cable runs can cause collisions to fall outside the 64 byte timing window, which is why observing the cable-length limits is so important.
There is an "interpacket gap", when the media is supposed to be quiet, of a certain size (amount of time, number of bits), also related to the network "diameter" (cable length[s]).
Note that introducing switches and full-duplex operation radically change certain aspects of this - if all is working correctly, there will never be a collision on a full duplex link. Because there can't be a collision, you could in theory get away with longer cabling runs. Your network can be larger, because the switch re-generates the packets anew if and when it sends them out.
Nevertheless, in practice, the packet size limits and cable length limits still apply (if you want reliable networking, that is), with certain notable exceptions (specifically, certain trunking encapsulations increase the maximum packet size a small amount; certain specific gigabit interfaces can transmit and receive "giant" frames).
There's an O'Reilly book, "Ethernet: The Definitive Guide", by Spurgeon, that might answer any other 'low level' detail questions you have.
HTH
John
