The structure of the RFC system

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

Request For Comment (RFC) System

Status Of This Memo

This memo is a report on RFC system. It contains information on the format of RFC documents explaining the significance of the important terms 'must', 'should', and 'may'. It also describes the operation of the Internet Control Message Protocol, and a summary of its' defined types.


The Request For Comments are documents describing recommendations for the internet technology. They are used by the Internet Engineering Task Force and other standard bodies. This memo describes the format for these documents. It also gives a detailed explanation of the Internet Control Message Protocol (ver 4) and consists of a checksum computation.

RFC Request For Comment (RFC) System January 2010

1. Introduction

This coursework written in an RFC style shows the structure of the RFC system. It also describes the Internet Control Message Protocol and how it could be used to create a program for reporting route taken by a packet from one host to another.

The report is numbered based on the arrangement of the questions in the coursework and the answers have been constructed using materials found on the web.

2. EE403B Coursework Questions And Answers

Structure Of The RFC System.

The RFC (Request for Comments) system contains technical and organizational documents about the Internet. It includes technical specifications and policy documents produced by the Internet Engineering Task Force (IETF). An RFC document is a document which represents technical theories or ideas proposed by researchers or developers and are made available for the internet community to view and comment upon.

The ultimate goal of an RFC publication process is to produce documents that are readable, clear, consistent, and reasonably uniform. The publication process will be much faster and more effective in creating readable documents if authors follow the rules and accept the guidelines contained in this document.

The General Rules For Writing RFC Documents are:

  • RFC publication language is English
  • Each line is limited to 72 characters long
  • Each page is limited to 58 lines of text
  • Each page except for the first and last page, must have same number of lines of text which header and footers are inserted

All published RFC documents must be guided by the structure shown below.

1. First-page header [Required]

2. Title [Required]

3. Abstract [Required]

4. Header Boilerplate [Required]

5. IESG Note [As requested by IESG]

6. Copyright and License Notice [Required]

7. Table of Contents [Required for docs with 30+ pgs]

8. Body of the Memo [Required]

8a. Introduction [Required]

8b. Requirement Words (RFC 2119)

8c. ...


8t. ...

8u. Security Considerations [Required]

8v. IANA Considerations

8w. Appendixes

8x. References

8y. Contributors

8z. Acknowledgments

9. Author's Address [Required]

The order shown is required, except that the order shown within the body of the memo is generally recommended but not required.

The body of the memo will normally have numbered sections; appendixes may be numbered or labeled. However, if the author chooses to label appendixes, subsequent sections should not be numbered. The elements preceding and following the body of the memo should be unnumbered.

First Page Header

The First page header is a required field in the structure of an RFC document. It is located at the top of the RFC document and consists of the author information, as well as an update or obsoletes section if there is a previously written RFC document of the same topic.

  • Author Organizations/Affiliations This consists of the name of the author, organization or affiliations associated with the author. If authors provide their affiliations in the header of the Internet Draft, the RFC will follow suit, and vice versa.
  • Updates and Obsoletes When authors produce a document that obsoletes or updates a previously published RFC(s), this information should be indicated clearly, preferably in the header.

Clearly stating this informationhelps call attention to the RFC Editor that other actions are necessary (e.g., insert additional fields in the RFC header and update the corresponding database entries).


The RFC title must be centered, preceded by, and followed by at least one blank line.

Choosing a good title for an RFC can be a challenge. A good title should fairly represent the scope and purpose of the document without being either too general or too specific.

Abbreviations (e.g., acronyms) [ABBR] in a title (as well as the Abstract and the body) must generally be expanded when first encountered. The exception is abbreviations that are so common that every participant in the IETF can be expected to recognize them immediately; examples include (but are not limited to) TCP, IP, SNMP, and FTP. Some cases are marginal, and the decision on expansion may depend upon the specific title.


Every RFC must have an Abstract section, a maximum of 20 lines. The Abstract section should provide a concise and comprehensive overview of the purpose and contents of the entire document, to give a technically knowledgeable reader a general overview of the function of the document.

Composing a useful Abstract generally requires thought and care. Usually an Abstract should begin with a phrase like "This memo ..."or "This document ...". A satisfactory abstract can often be constructed in part from material within the Introduction section, but an effective abstract may be shorter, less detailed, and perhaps broader in scope than the Introduction. Simply copying and pasting the first few paragraphs of the Introduction is allowed, but it may result in an Abstract that is both incomplete and redundant. Note also that an Abstract is not a substitute for an Introduction; the RFC should be self-contained as if there were no Abstract section.

Abstracts must not contain citations and abbreviations appearing in the Abstract should generally be expanded in parentheses, with the exceptions noted above. When in doubt, expand an abbreviation (refer to the online "Table of decisions on consistent usage of terms in RFCs" [PubProcess]).

Header Boilerplate

This part of the structure of an RFC consists of a short copyright, and a Status of Memo. The status of memo is a required field and gives overview of the RFC document.


This text will be provided to the RFC Editor by the IESG and will be inserted into the RFC text.

Copyright And License Notice

This text will be provided by the RFC Editor and will be inserted into the RFC text.

Table Of Contents

A Table of Contents (TOC) section is required in RFCs longer than 30 pages and recommended for an RFC longer than 15 pages. It must be positioned after the Abstract and before the Introduction section.

The TOC itself should not be too long or detailed, or it loses value. For example, if many successive TOC entries point to the same pages of the memo, the TOC granularity probably needs to be coarser.

The RFC Editor uses a program to generate and format the TOC at the final stage of editing an RFC.

Body Of The Memo

Following the Table of Contents, if any, comes the body of the memo. Depending upon the length of the TOC, a judicious page break before the body can improve readability.

Each RFC should start with an "Introduction" section that (among other things) explains the motivation for the RFC and (if appropriate) describes the applicability of the document, e.g., whether it specifies a protocol, provides a discussion of some problem, is simply of interest to the Internet community, or provides a status report on some activity. The body of the memo and the Abstract must be self-contained and separable. This may result in some duplication of text between the Abstract and the Introduction; this is acceptable.

The body of the Memo starts with the Introduction section that explains the motivation for the RFC and describes the applicability of the document.

Authors' Address Section

This required section gives contact information for the author(s) listed in the first-page header, and perhaps those listed in a Contributors section. Contact information must include at least one, and ideally would include all, of a postal address, a telephone number and/or FAX number, and a long-lived email address.

Significance Of The Terms 'MUST', 'SHOULD', And 'MAY'.

The need for accuracy is important when writing an RFC because a slight confussion could cause problems. The words 'MUST', 'SHOULD', and '�MAY' are capitalized words and their specific meanings are defined in the RFC 2119. The definition of these three words are expected to remain consistent between RFCs.

  • MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.
  • SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
  • "MAY"

This word or the adjective "OPTIONAL" means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item.

The definitions of MUST, SHOULD and MAY are given above, with reference to RFC 2119.

What Relationship Can Exist Between Different RFC Documents Several relationships can exist between different RFCs and they are as listed below:


A RFC can be an updated version of previously written RFCs on the same subject but with updated technical views and knowledge.


A RFC can be written to obsolete or to replace previously written RFCs. This can happen where the new RFC covers the


A RFC can be written using some of the information provided on other RFCs.

2.2) RFC that describes the (ver 4) of Internet Control Message Protocol on the internet, method used to find it, location of the document, and the numbers of any RFCs related to it.

RFC 792 is the RFC that describes the (ver 4) of ICMP on the internet. J. Postel is the author of this RFC and its date of acceptance is September 1981.

I searched for this RFC by providing the keywords ��Internet Control Message Protocol�� in the search engine provided at In the list of RFCs returned by the search engine, I found two RFCs that best describes the ICMP, the RFC 792 and RFC 777. RFC 777 is displayed in gray colour meaning that it has been obsoleted by the RFC 792.

RFC 792 updates the content of RFC 777 and 760. RFC 777 is written by Jon Postel in 1981 which provided a preliminary description of the Internet Control Message Protocol version 4 and RFC 792 is a more updated version with more content such as Information Request and Reply Messages. RFC 792 obsoletes RFC 777 because it contains the information provided by RFC 777 but with more updated information about the ICMPv4. RFC 760 was written for the United States' Defense Advanced Research Projects Agency (DARPA), also by Jon Postel. It provides a very detailed description of the Internet Protocol.

2.3) Describe using the current (ver 4)ICMP RFC, how the ICMP protocol works. Include a description of the ICMP message field and a summary of the defined types of ICMP message.

How The ICMP Protocol Works

The ICMPv4 is adopted for IPv4 and is generally used for network error and status reporting, it works at the transport layer. The errors reported by ICMP are generally related to and IP datagram processing. ICMP only reports errors involving fragment 0 of any fragmented datagram. The IP, UDP or TCP layer will usually take action based on ICMP messages.

A general characteristic of ICMP operation is that when errors found, they are reported immediately using the ICMP but only to the original source of datagram.

The Internet Control Message Protocol (ICMP) [RFC792] protocol is a client server application. The ICMP server executes on all IP end system computers and all IP intermediate systems (i.e routers). The protocol is used to report problems with delivery of IP datagrams within an IP network. It can be sued to show when a particular End System (ES) is not responding, when an IP network is not reachable, when a node is overloaded, when an error occurs in the IP header information, etc. The protocol is also frequently used by Internet managers to verify correct operations of End Systems (ES) and to check that routers are correctly routing packets to the specified destination address.

Description Of The ICMP Message Field

A description of an ICMP message field is shown below:


| + | Bits 0 - 3| 4 �V 7 | 8 - 15 | 16 - 18 | 19 - 31|


| 0 | Version |Header length|Type of service| Total Length |


| 32 | Identification |Flags| Frag. offset |


| 64 | Time to live | Protocol | Header checksum |


| 96 | Source address |


| 128 | Destination address |


| 160 | Options |


| 160 | |

| or | Data |

| 192+| |



This field specifies which version of IP the datagram is using. In this case, this field has a value of 4 indicating it��s using IPv4.


IHL stands for Internet Header Length. This field takes a 4-bit value which specifies the number of 32-bit words in the header. The minimum value is 5 because the minimum length of a datagram is 160 bits (5 x 32 = 160 bits). Obviously, the maximum value is 15 since it is a 4-bit value.

Type Of Service

The original intention of this field is to specify a preference for how the datagram would be handled. The options are as follows:

bits 0-2: precedence

bit 3: 0 = Normal Delay, 1 = Low Delay

bit 4: 0 = Normal Throughput, 1 = High Throughput

bit 5: 0 = Normal Reliability, 1 = High Reliability

bits 6-7: Reserved for future use

In this case, for ICMP, this field takes a value of 0.

Total Length

This field defines the size of the entire datagram, the total length of the internet header and data in octets.

Identification, Flags, Fragment Offset

The identification field is used to give fragments of a datagram a specific ID so they can be traced. Flags field is a 3-bit field which is used to control or identify fragments. Fragment offset specifies the offset of the fragment relative to the beginning of the original, unfragmented IP datagram.

Time To Live

An 8-bit field which specifies the length of time the datagram should persist for in seconds. This value is decremented at each machine which processes it and so this value must be at least as great as the number of gateways which this datagram will traverse.


This field specifies the protocol used in the data portion of the IP datagram. In this case, for ICMP, this field takes a value of 1.

Header Checksum

This field is used for error-checking of the header. At each hop, the checksum of the header must be compared to the value of this field. If a header checksum is found to be mismatched, then the packet is discarded.

Source Address

This field takes an IP address, a value of 4x 8-bit octets, a total of 32 bits. The address taken in this field is the address of the gateway of the sender of the packet.

Destination Address

This field takes an IP address, a value of 4x 8-bit octets, a total of 32 bits. The address taken in this field is the address of the gateway of the receiver of the packet.


This field is not part of the header. The content of the data is specified in the protocol header field. This can be any one of the protocols in the transport layer such as ICMP, TCP and UDP.

Summary Of The Defined Types Of ICMP Message Types

Here is a list of the defined ICMP types in RFC 792:

a) Destination unreachable Message

b) Time Exceeded Message

c) Parameter Problem Message

d) Source Quench Message

e) Redirect Message

f) Echo Request or Echo Reply Message

g) Timestamp or Timestamp Reply Message

h) Information Request or Information Reply Message

Each of these types has a specific ID which goes into the type parameter of the ICMP message header. These values are given in the previous section.

a) Destination Unreachable Message

This type of message indicates that the datagram cannot be sent to the destination specified in the destination address field in the IP header of the datagram. There can be several cases which this could occur.

For example, if a gateway is able to determine that the destination host is unreachable then it may send a destination unreachable message to the source host.

b) Time Exceeded Message

This type of ICMP message indicates that a datagram is discarded due to the fact that its time to live field has become zero. A gateway may be able to detect this and sends a time exceeded message back to the source host. Another possible case is that a host is unable to complete the reassembly of a fragmented datagram within its time limit and so the datagram is discarded. In such case, the host may also send a time exceeded message. Code 0 (time to live exceeded in transit) may be received from a gateway and code 1 (fragment reassembly time exceeded) may be received from a host.

c) Parameter Problem Message

If there is an error in the parameters of the IP header which prevents the datagram from being processed completely, the gateway or host processing the datagram will have to discard the datagram. It may then send a parameter problem message on the problem found in the datagram back to the source host.

For this type of message, there is an extra parameter in the ICMP message header called Pointer. It is an 8-bit field which specifies an offset which points to the byte location of the error which caused the parameter problem message to be sent.

d) Source Quench Message

A source quench message may be sent by a gateway because it has discarded a datagram due to the lack of buffer space required to queue the datagram. Another possible case where this type of ICMP message is sent is where a destination host has discarded a datagram because it cannot process the datagrams quick enough. A source quench message simply acts as a notification to the source host to cut down its transmission rate. A source host can keep cutting the transmission rate until it no longer receives source quench messages and it can then increase the rate until it starts receiving source quench messages.

e) Redirect Message

A redirect message is sent by a gateway to notify the source host that there is a shorter path to the destination host. An exception is where a datagram with the IP source route options and the gateway address in the destination address field. In such cases, a redirect message will not be sent even if there is a shorter route than the next address in the source route.

f) Echo Request or Echo Reply Message

An echo message request may be sent by a source host to test if the destination host exists. A source host will know that the destination host indeed exists if it receives a echo reply message which contains the same data that was sent with the echo message request.

The header of this type of ICMP message has two extra fields, identifier and sequence. Both fields take a 16-bit value. Both fields can be used to help in the matching of echo request and echo reply messages.

g) Timestamp or Timestamp Reply Message

This type of ICMP message allows devices to exchange time information.

This can help two devices to minimize their time differentials.

There are three additional fields from the ICMP message header for echo request/reply messages. The additional fields are Originate Timestamp which indicates the time the sender sent the timestamp message; the Receive timestamp, the time at which the receiver handled the message; the Transmit timestamp, the time the echoer transmitted the reply message. The timestamp is 32 bits of milliseconds since midnight UT.

The purpose of the identifier and sequence fields remain the same as for echo request/reply messages.

h) Information Request or Information Reply Message

This type of message allows a host to find out the number of the network it is on. A information request message may be sent with the source network in the IP header source and destination address fields zero, indicating ��this�� network. The IP module which would reply to this request message should send an information reply message with the address fields fully specified. This type of ICMP message has the same message header as the echo request/reply message and so the purposes of the identifier and sequence fields remain the same.

2.4) Describe how ICMP can be used to create a program that can report the route taken by a packet from one host to another.

Traceroute is a computer network tool used to determine the route taken by packets across an IP network. Traceroute reports the route taken by a packet from one host to another.

Traceroute works by increasing the "time-to-live" value of each successive batch of packets sent. The first three packets sent have a time-to-live (TTL) value of one (implying that they are not forwarded by the next router and make only a single hop). The next three packets have a TTL value of 2, and so on. When a packet passes through a host, normally the host decrements the TTL value by one, and forwards the packet to the next host. When a packet with a TTL of one reaches a host, the host discards the packet and sends an ICMP time exceeded (type 11) packet to the sender. The traceroute utility uses these returning packets to produce a list of hosts that the packets have traversed en route to the destination. The three timestamp values returned for each host along the path are the delay (aka latency) values typically in milliseconds (ms) for each packet in the batch. If a packet does not return within the expected timeout window, a star (asterisk) is traditionally printed.

Traceroute may not list the real hosts. It indicates that the first host is at one hop, the second host at two hops, etc. IP does not guarantee that all the packets take the same route.

2.5) Computation of Checksum For ICMP (ver 4) ECHO message

For this computation, non-zero values have been choosen for the parameters required. Full details of the calculation are shown below.

At the sending node, the checksum is calculated

type = 8

code = 0

identifier = 1

type & code 00001000 00000000

check sum 00000000 00000000

Identifier 00000000 00000001

Sequence 01000000 01000000

Data 01000000 00100000

00000000 01000000

Ones complement sum 10001000 10100001

At the receiving node, the checksum is calculated and then compared

to that received from the sending node to see if there are errors.

type & code 00001000 00000000

check sum 01110111 01011110

Identifier 00000000 00000001

Sequence 01000000 01000000

Data 01000000 00100000

00000000 01000000

Ones complement sum 11111111 11111111

The checksum is run again to check if there are any errors.

If the sum results are inverted (1's Compliment) to 0000 0000, then

there are no errors but if there are any 1's in the new results,

then an error has occured.

It was assumed that an error occured at the 21th bit of the data.

The data bit was changed from a "0" to a "1".

type & code 00001000 00000000

check sum 01110111 01011110

Identifier 00000000 00000001

Sequence 01000000 01000000

Data 01000100 00100000

00010000 01000000

Ones complement sum 10001111 11111111

Inversion of the sum results gives 01110000 00000 which indicates

that an error has occured.

2.6) Suggest An Application For The ICMP timestamp Message Indicating briefly hoe it would be implemented.

The ICMP timestamp is an ICMP message which is mainly used for time sychronization.

The ICMP timestamp ping is useful for non-filtered network connections. If a firewall is in use, this ping option may not provide any successful responses.

The ICMP timestamp message from the sender would has the format shown below:


0 - 7 8 - 15 16 - 31 *


Type = 13 Code = 0 Header Checksum *


Identifier Sequence Number *


Originate Timestamp


Besides the ICMP timestamp message, there is also the timestamp

reply message which contains the timestamp sent by the sender,

a receive timestamp, and a transmit timestamp as shown below:


0 - 7 8 - 15 16 - 31 *


Type = 13 Code = 0 Header Checksum *


Identifier Sequence Number *


Originate Timestamp


Receive Timestamp


Transmit Timestamp [8]


An ICMP timestamp ping operates similarly to other ICMP-based pings.

The source sends an ICMP Get Timestamp message and waits for an ICMP Send Timestamp response.

If the remote device doesn't respond, the ping fails and the scan does not proceed.

Source Destination Summary


[] [] ICMP: C Get timestamp

[] [] ICMP: R Timestamp

ICMP is often filtered through firewalls and packet filters. If this ping works, then the network link between the nmap station and the remote device is most likely wide open. The ICMP timestamp ping relies on ICMP, which is often prevented from traversing firewalls or packet filters. The ICMP timestamp ping will only work for privileged users. Nmap will modify the ping for non-privileged users to use a TCP connect. Since a TCP connect initializes application sessions when accessing an open port, it's important to understand the implications of using this ping type with a non-privileged user.

Security Considerations

There are no security considerations regarding this report.


[1] Braden R. (ed.), "RFC Document Style", available at: [accessed 2ndJan,2010]







Internet Program Protocol Specification," RFC 792, USC/Information Sciences Institute, September 1981.

[8] Braden, R. (ed.), "Requirements for Internet Hosts - DARPA

Internet Program Protocol Specification," RFC 1122, USC/Information Sciences Institute, October 1989.