RFC 791 was written in 1981 for DARPA (Defense Advanced Research Projects Agency) by the Information Sciences Institute University of Southern California. The document is broken into three sections, Introduction, Overview, and Specifications. Although the Introduction and Overview have very good information this summary will focus on the specifications but will highlight afew sections from the overview. #### Header As seen in the Frames and Packets article on this site the IP header looks like:

IPv4 Header (32 bits)
Starting Byte	Byte								Byte								Byte								Byte
	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	Version				IHL (header Len)				Type Of Server (TOS)								Total Length
4	Identification																IP Flag			Fragment Offset
8	Time To Line (TTL)								Protocol								Header Checksum
12	Source Address
16	Destination Address
20	IP Option (Variable Length, Optional, not common)

#### Header Details As you can see the datagram contains several elements. The function for each element is: * Version - RFC 791 specifically refers to version 4 * Internet Header Length (IHL) - Informs the recieving systems the length of the header and when data begins * Type of Service (TOS) - This 8 bit value is used for quality of service. * bit 0-2 are for Precedence * 000 - Routine * 001 - Priority * 010 - Immediate * 011 - Flash * 100 - Flash Override * 101 - CRITIC/ECP * 110 - Internetwork Control * 111 - Network Control * bit 3 is for Normal delay (0) or low delay (1) * bit 4 is for Normal throughput (0) or High throughput (1) * bit 5 is for Normal reliability (0) or High reliability (1) * When RFC 791 was written bit 6 and 7 where reservered for future use * Total Length - Is the total length of the datagram in bytes up to 65535 octets. However a system must be able to accept a minimum of 567 octets. * Identification - Used in re-assembling fragmented datagrams * Flags - used with datagram fragmentation * bit 0 is reserved and must be 0 * bit 1 if set to 0 allows a datagram to be fragemented. If set to 1 the datagram cannot be fragmented * bit 2 if set to 0 indicated the last fragement. If set to 1 more fragments are coming * Fragment Offset - Tells the systems performing the datagram fragementation where it can fragment * Time to Live - Indicated how long the datagram can persist on the network. If it reaches 0 the datagram must be discarded * Protocol - Indicates the next level protocol used in the datagram * Header Checksum - Validates the datagram at each point through the network * Source Address - 32 bits * Destination Address - 32 bits * Options - There are lots of IPv4 options that may or may not be applied. For additional details please read the full RFC specifically page 15 - 22 * At the end of the header the datagram is padded with 0's until it ends on a 32 bit boundry #### RFC summary As with all RFC's this RFC requires that any indivdual that implements the IP datagram align with the standard such that any party may interact with the datagram on diverse systems. In Section 3 the IPv4 addressing schema is discussed in length as are the functions summarized above. In relation to IPv4 this RFC defines Class A, B, and C network sizes. Class A allocates 7 bits for network and 24 bits for hosts. Class B allocates 14 bits for network and 16 bits for hosts. Class C allocates 21 bits for network and 8 bits for hosts. In addition to addressing schemes the specific functions of datagram fragmentation and re-assembly are discussed in great detail within the RFC. Specifying that some options may or may not be included when a packet is fragmented. Refering back to a previous statment about implementing the IP Datagram the RFC also gives examples about what should be presented to upper layer protocols for configuration elements to faciliate an easier communication and configuration between systems. These elemenets are the same elements used to construct the datagram.