28

TCP/IP Professional Reference Guide

international board of directors. The IANA is responsible for Internet protocol addresses, domain names, and protocol parameters and serves as the central coordinating location for the Internet. The IANA dates to the creation of the Internet and was originally funded by the NSF. Due to international growth, it was felt that it would be more appropriate for IANAs activities to be supported by organizations that rely upon it. Thus, the IANA converted into a new, not-for-prot organization. Its role remains the same; although the IAB is responsible for RFCs, the IANA retains responsibility for any new numbering required to identify protocols, ports, or other components of the TCP/IP protocol suite. Thus, careful coordination between the IAB and IANA is required to ensure that RFCs do not adversely impact the TCP/IP protocol suite. Given an appreciation for the governing bodies of the Internet related to the development of RFCs, one can now focus on to the manner by which the TCP/IP protocol suite is standardized by examining a Request for Comments.

Request for Comments

As noted earlier in this chapter, Request for Comments (RFCs) are documents that dene the TCP/IP protocol suite. For the most part, RFCs are technical documents. However, they can cover a variety of topics to include an instruction for authors that denes the procedures for writing an RFC. There are currently over 2700 RFCs, and it was not until RFC 1543 that instructions for the author were standardized.

The Standards Process

Anyone can submit an RFC. However, the primary source of such documents is the IETF. The actual submission of an RFC begins as a memorandum that is reviewed by the Internet Engineering Steering Group (IESG) that operates under the IAB. If the memorandum is approved, the IESG sends it to an RFC editor. At this point in time, the document becomes a draft RFC.

Draft RFC
A draft RFC is considered a public document, and a peer review process occurs during which comments are received and reviewed concerning whether or not the RFC removes its draft status and is distributed as an RFC standard.

Proposed Standard and Draft Standard

An RFC is normally issued as a preliminary draft. After a period of time allowed for comments, the RFC will normally be published as a proposed standard. However, if circumstances warrant, the RFC draft can also be dropped from

Internet Governing Bodies and The Standards Process

29

Exhibit 3.1

Internet Standards Track Time

consideration. Assuming that favorable or a lack of nonfavorable comments occur concerning the proposed standard, it can be promoted to a draft standard after a minimum period of six months.

RFC Standard
After a review period of at least four months, the Internet Engineering Steering Group (IESG) can recommend a draft standard for adoption as a standard. Although the IESG must recommend the adoption of an RFC as a standard, the IAB is responsible for the nal decision concerning its adoption. Exhibit 3.1 illustrates the previously mentioned time track for the development of an RFC that represents both an Internet and TCP/IP protocol suite standard. As indicated in Exhibit 3.1, a minimum of ten months is required for an RFC to be standardized, and many times the process can require several years.

RFC Details
Once issued, an RFC is never revised; instead, an RFC is updated by new RFCs. When this situation occurs, the new RFC will indicate that it obsoletes or updates a previously published one.

RFC Categories
There are currently three categories of RFCs: Track, Informational, and Experimental. A Standards Track RFC species an Internet Standards Track protocol for the Internet community and requests discussion and suggestions for improvement. An Informational RFC provides information for the Internet community and does not specify an Internet Standard of any kind. The third category for RFCs is Experimental, which denes an experimental protocol for the Internet community that may or may not be adapted by the community.

Accessing RFCs
There are several locations on the Internet that maintain a repository of RFCs. Two such organizations are the RFC-Editor, a public organization, and Ohio

30

TCP/IP Professional Reference Guide

State University. In addition, one can also join several mailing groups to obtain RFC announcements. If one enters the keyword RFC index in a Web search engine, one can usually retrieve several locations where one can point the browser to access a list of RFCs. The RFC-Editor and Ohio State University operate very useful Web sites for accessing and retrieving RFCs, and probably should be considered prior to using other sites. Exhibit 3.2 illustrates the home page of the RFC-Editor. Its Web address is http://www.rfc-editor.org/rfc.html. In examining Exhibit 3.2, note that one can search for a RFC by number, author, title, date, or keyword. In addition, one can retrieve RFCs by number and category or use the screen shown in Exhibit 3.2 to access the ability to search for and retrieve RFC. The Computer and Information Science Department of Ohio State University operates a second Web site that warrants consideration in a search for RFCs. The Uniform Resource Locator (URL) of this site is http://www.cis.hiostate.edu/hypertext/information/rfc.html. Exhibit 3.3 illustrates RFC-Editor and Ohio State Universitys support and retrieval of RFCs in a number of ways that include a keyword search. In addition, the Ohio State University Web site provides access to an Internet Users Glossary and other documents that can be a valuable addition to anyones Web library. In concluding this examination of RFC sites, it will probably be of interest to many readers to view portions of an RFC. If one selects the Index retrieval method shown in Exhibit 3.3 and scrolls down the resulting display, one notes recently published RFCs. An example of this action is shown in Exhibit 3.4, where the Ohio State University site contained 2719 online RFCs when it was accessed by this author. In examining the entries in Exhibit 3.4, note the common format used for displaying a summary of RFCs. After the RFC number is displayed in the left margin, the title of the RFC is followed by the authors publication date, RFC format, and status. Although all RFCs must be written in 7-bit ASCII text, an approved secondary publication is in postscript. Note that by indicating the number of bytes required for storing the RFC, the index allows one to consider if one should download it via an existing connection that might not provide the bandwidth required for an expedient delivery, or if one should request its delivery via e-mail if time is not of the essence. As another option, if accessing the Index from home, one might consider waiting a return to work to access via a higher speed connection a lengthy document needed. To illustrate the general format of an RFC, examine the relatively recent document, RFC 2710 Multicast Listener Discovery (MLD) for IPv6. From the Index listing shown in Exhibit 3.4, one sees that it is a proposed standard. By clicking on the RFC number 2710 shown in the left column in Exhibit 3.4, a display of the RFC of interest is obtained. Exhibit 3.5 illustrates the view through a Web browser of the top portion of the beginning of the RFC. In examining Exhibit 3.5, note that the persons responsible for the RFC and their afliations are listed at the beginning of the

Internet Governing Bodies and The Standards Process

Exhibit 3.2 The Public Rfc-Editor Provides Several Methods for Finding and Retrieving RFCs

31

32

TCP/IP Professional Reference Guide

Exhibit 3.3 Viewing Access to RFCs via the Computer and Information Science Department of Ohio State University

Internet Governing Bodies and The Standards Process

Exhibit 3.4 Viewing a Portion of the Ohio State University RFC Index List

33

34

TCP/IP Professional Reference Guide

Exhibit 3.5 Viewing the Initial Portion of RFC 2710

Internet Governing Bodies and The Standards Process

35

document as is the date of publication of the document. If this RFC obsoleted or updated a prior RFC, one would then note a line before the category line on the left side that would indicate the RFC number that was obsoleted or updated. Because the RFC viewed in Exhibit 3.5 did not obsolete or update a previously published RFC, that line was omitted from the document. Continuing the examination of the structure of an RFC, note that the title appears on a line below the submission date. Under the title is a status section that contains a paragraph that describes the RFC. Each RFC must include on its rst page a Status of this Memo section, which functions as a brief introduction to the RFC. Here, the term Memo is used, in actuality, as a memo following a format and structure evolves into an RFC. In continuing to view the contents of an RFC, one will encounter a copyright notice, followed by an abstract of the document. Some documents will also include a table of contents, followed by the body of the document. Most modern RFCs now terminate with three sections. The second from the last section contains a section titled Authors Addresses, which lists the authors, their organization, mailing address, telephone number, and e-mail address. The next to last section in the RFC contains a complete copyright notice. The last section in an RFC contains an acknowledgment section. Thus, the basic RFC provides information on how to contact the authors as well as a detailed description of the technology it is dening.

Chapter 4

The Internet Protocol and Related Protocols

The focus of this chapter is on the rst layer of the TCP/IP protocol suite. While the Internet Protocol (IP) is the primary protocol most people associate with the network layer, there are two related protocols that must be considered when discussing the TCP/IP protocol suite. Those protocols are the Address Resolution Protocol (ARP) and the Internet Control Message Protocol (ICMP). This chapter focuses attention on what this author commonly refers to as the Network Layer Troika of the TCP/IP protocol suite: IP, ARP, and ICMP. In examining the Internet Protocol, pay particular attention to the structure of the IP header and its elds, which are examined by routers as a mechanism for making forwarding decisions. Another specic IP area of focus is addressing, as the composition of IP addresses determines the manner by which datagrams are routed from source to destination, as well as the number of hosts that can be connected to a specic type of network. In addition, in examining IP addressing, this chapter also discusses several little-known areas of the IP protocol that having knowledge about can provide the user with network design and operation exibility. Two examples of such topics are the assignment of multiple network addresses to an interface and the use of a zero subnet. Because the ltering of IP datagrams by routers and rewalls can occur based on IP addresses, as well as ICMP message types and control eld values, the information presented in this chapter will also provide a rm foundation for discussion of security in a later chapter in this book. The initial focus in this chapter is on the IP protocol, to include its use for routing datagrams across a network and between interconnected networks. The composition of the IP header and the use of different elds in the header are examined in detail. Once this is accomplished, attention turns to the role
37

38

TCP/IP Professional Reference Guide

and operation of the Address Resolution Protocol (ARP) and includes examining the rationale for a little-known ARP technique that can considerably facilitate the operation of delay-sensitive transmissions, such as Voice over IP. A discussion of Internet Control Message Protocol (ICMP) concludes this chapter. Because some ICMP types of messages are commonly used by hackers as a mechanism to begin an attack upon a network, information about ICMP presented in this chapter will be used when examining security as a separate entity later in this book.

The Internet Protocol

The Internet Protocol (IP) represents the network layer of the TCP/IP protocol suite. IP was developed as a mechanism to interconnect packet-switched TCP/IP-based networks to form an internet. Here, the term internet with a lower case i is used to represent the connection of two or more TCP/IPbased networks.

Datagrams and Segments

The Internet Protocol transmits blocks of data referred to as datagrams. As indicated in Chapter 2, IP receives upper layer protocol data containing either a TCP or UDP header, referred to as a TCP segment or UDP datagram. The prex of an IP header to the TCP segment or UDP datagram results in the formation of an IP datagram. This datagram contains a destination IP address that is used for routing purposes.

Datagrams and Datagram Transmission

To alleviate potential confusion between datagrams and an obsolete transmission method referred to as datagram transmission, a few words are in order. When the ARPAnet evolved, two methods of packet transmission were experimented with. One method was referred to as datagram transmission and avoided the use of routers to perform table lookups. Under datagram transmission, each node in a network transmits a received datagram onto all ports other than the port the datagram was received on. While this technique avoids the need for routing table lookup operations, it can result in duplicate datagrams being received at certain points within a network. This results in the necessity to develop software to discard duplicate datagrams, adding an additional level of complexity to networking. Thus, datagram transmission was soon discarded in favor of the creation of virtual circuits that represent a temporary path established between source and destination. When referring to datagram transmission in the remainder of this book, one is actually referencing the transmission of datagrams via a virtual circuit created between source and destination.