Dec 142010

As one of the long term moderators at the Petri website I often see questions which could be easily found or answered. A lot of these questions are regarding protocols such as FTP, HTTP or DHCP.

I know for sure that the vast majority of IT professionals are already aware of this and I’m sure the most of the IT professionals just look the questions up on google for example. And maybe the more experienced IT professionals will read the Request for Comments, or also called the RFCs.

But for the less experienced people is where I’m currently targeting on. This is more because I think that RFCs are a very important part when you work with protocols.

But what is actually an Request For Comment?
Wikipedia will tell you; In computer network engineering, a Request for Comments (RFC) is a memorandum published by the Internet Engineering Task Force (IETF) describing methods, behaviors, research, or innovations applicable to the working of the Internet and Internet-connected systems.

So with other words, it’s a documents which desribes standards for our important part of the job, for example protocols like DHCP, HTTP and FTP.

Ok, lets take DHCP as an example. Often I see questions if it is possible to force a client to use a certain DHCP server. Well the answer is no, since DHCP uses a broadcast mechanism to find a DHCP server. The first one who responds will serve the IP address.

So lets take a look at the RFC 2131 which describes the Dynamic Host Configuration Protocol or DHCP.
As you can see it’s a document about 45 pages. I’m not going to tell you how to read it but I’ll show you where you can find the answer to the question above.

If you skip to page 13 section 3.1 you’ll find the following text: The client broadcasts a DHCPDISCOVER message[…]
Errr? But what does it do? Well if you scroll a bit futher you’ll find a small definition about the the DHCPDISCOVER namely: DHCPDISCOVER – Client broadcast to locate available servers.
So actually they are telling that it sends out a certain packet to find DHCP Servers. This means that there is no option available to select a certain server. Of course you can force it by temporarly disable the other DHCP serves but that is not the point of this post. The point is that a lot of such questions is doucmented very very well.

A nice sheme how the DHCP process works can be found at page 14. If you scroll a bit further you also find the explanation of the process.

The same of course applies to HTTP/1.1 which is the current standard since about 1997.The RFC for DHCP is RFC 2616. This RFC consists of 176 pages. That’s quite a lot but knowing them is very useful, especially when you need to do advanced troubleshooting.

I don’t say you need to remember each of them, however you need to know where to find them. Just remember the website (which is the acronym of the Internet Engineering Task Force) where all those documents can be found, or use google to find them 🙂

However this is not the only publisher or standards. Another one is the IEEE or the Institute of Electrical and Electronics Engineers. This one is a more commercial website, however also extremly important.

For example, I hope you have heard of VLAN tagging. if not, please read this wikipedia link.
Anyhow the VLAN Tagging is defined in a IEEE 802.1Q standards. For all the 802.1 standard you can follow this link. Those documents basically provides the same kind of information as the IETF.

Both IETF and IEEE are extremly important in the current networks. I really suggest to read some of them to get an impression what it is and what it does. I think it will give you a great inside of the protocols and other network standards.

In fact, just a few days ago I actually used the RFC 959 which described the FTP protocol. So if you’re an advanced or a novice IT Professional, it really doesn’t matter. We all using them and if no we all should using them.
So since I got the feeling the RFCs doesn’t get the attention it should have I had the feeling to bring it back under the attenton again.