Here we need to side step a little. We need to first talk about what goes into making a
standard. Without standards, it makes communication between computers of different type very
difficult. Just like you have bus
standards like ISA
so hardware can communicate with the
CPU, you need some kind of standard.
In the Internet community,
standards are both suggested and established through Request for Comments or
RFCs. To some extent this is the "law". If one product claims to comply with a
particular RFC, you know that any other application that
does so should be able to communicate with it. However, RFCs include other
things such as lists of previous RFCs and basic introductions to things like
Becoming a standard is a three step process.
Usually, the first few paragraphs of an RFC
will tell you to what stage it applies. Assuming of
course, that the RFC
is part of a standards proposal. At the first stage, the standard is proposed.
Organizations then decide to implement the proposed standard. It requires three separate
implementations before the proposal becomes a standard. (Finally, it becomes a standard. This is an
oversimplication of the process, since there will also be a lot of discussion about the proposed
If you need information about a specific network
standard, the first place to look
is the most current RFC
index, which is also published as an RFC. Not only does this list all the
RFCs, but will also tell you if one RFC
has been replaced and by which one.
Originally I had
planned to include a list of the more commonly used and significant RFCs. I eventually realized that
this was an unending task. When I started this, there were just over 1800 RFCs. The last time I
checked before wrapping up this book, there are well over 2000. Instead I will simply tell you where
to get them.
The first place is from the "central repository." These are obtainable using ftp
from ftp.ds.internic.net. There is an rfc directory, which contains the RFCs in ASCII
as many in postscript format. If you know what RFC
you want, this can be obtained by sending an
email message to email@example.com. List each RFC
you want in the
where XXXX is the number of the RFC.
can obtain the index by including the entry:
In addition, the
RFCS are available from archives all over the Internet. However, rather than tying up the Internet
bandwidth with a lot of copy of files you may not need. Check out www.cdrom.com or mail
firstname.lastname@example.org. This is for Walnut Creek CD-ROM
and the sell a CD packed with thousands of
documents related to the Internet, including the RFCs. Another site with pretty much the same kind
of offering is InfoMagic. They can be reached at www.infomagic.com or
For Linux systems running TCP/IP one of the most important
standards deals with Ethernet.
(packaging) of IP
datagrams is defined for Ethernet
894. Developed in 1982 by Digital Equipment Corporation (DEC), Intel and Xerox Ethernet
(spelled with a capital) is a standard, rather than a physical entity. Several years later, the 802
Committee of the Institute of Electrical and Electronic Engineers (IEEE or I-triple E), published
standards of its own that differed in many ways from the original Ethernet
these are referred to as the 802 IEEE standards. The 802.3 standard covers networks similar to
Ethernet. The IEEE 802 encapsulation
was defined in RFC
1042. Both of these use an access method
called Carrier Sense Multiple Access with Collision Detection or CSMA/CD.
Both of these
framing types (RFC 894 and RFC
1042) use a 48-bit addressing scheme. These are generally referred to
as the MAC or hardware address.
The six bytes of both the destination and source machine are
included in the header
of both framing types. however, the remainder of the frame is different. As
we talked about earlier, this layer is responsible for sending and receiving the IP
datagrams. It is
also responsible for sending and receiving other kinds of packets as well. These are packets from
the Address Resolution Protocol (ARP) and the Reverse Address Resolution Protocol (RARP). We'll
talk about both later on.