RFC 791 foi escrito em 1981 para DARPA (Defense Advanced Research Projects Agency) pela Information Sciences Institute University of Southern California. O documento é quebrado em três seções, Introdução, Visão geral e especificações. Embora a Introdução e Visão Geral tenham informações muito boas, este resumo se concentrará nas especificações, mas destacará algumas seções da visão geral.

Cabeçalho

Como visto no artigo Frames and Packets neste site o cabeçalho IP se parece com:

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)

Detalhes do Cabeçalho

Como você pode ver o datagram contém vários elementos. A função para cada elemento é:

Versão - RFC 791 refere-se especificamente à versão 4
Internet Header Length (IHL) - Informa os sistemas de recepção do comprimento do cabeçalho e quando os dados começam
Tipo de Serviço (TOS) - Este valor de 8 bits é usado para a qualidade do serviço.
- bit 0-2 são para Precedência
  - 000 - Rotina
  - 001 - Prioridade
  - 010 - Imediato
  - 011 - Flash
  - 100 - Substituição por Flash
  - 101 - CRITÉRIO/PCE
  - 110 - Controle de Internetwork
  - 111 - Controle de Rede
- bit 3 é para atraso normal (0) ou atraso baixo (1)
- bit 4 é para rendimento normal (0) ou alto rendimento (1)
- bit 5 é para confiabilidade normal (0) ou alta confiabilidade (1)
- Quando RFC 791 foi escrito bits 6 e 7 onde reservado para uso futuro
Comprimento total - É o comprimento total do datagram em bytes até 65535 octets. No entanto, um sistema deve ser capaz de aceitar um mínimo de 567 octets.
Identificação - Usado para remontar os gráficos de dados fragmentados
Bandeiras - usadas com fragmentação de datagram
- bit 0 é reservado e deve ser 0
- bit 1 se definido como 0 permite que um datagram seja fragmentado. Se configurado para 1 o datagram não pode ser fragmentado
- bit 2 se ajustado para 0 indicou o último fragement. Se definido para 1 mais fragmentos estão chegando
Fragmento Offset - Diz aos sistemas que realizam a fragmentação de datagram onde pode fragmentar
Time to Live - Indicado quanto tempo o datagram pode persistir na rede. Se atingir 0 o datagram deve ser eliminado
Protocolo - Indica o próximo nível de protocolo utilizado no datagram
Header Checksum - Valida o datagram em cada ponto através da rede
Endereço de origem - 32 bits
Endereço de destino - 32 bits
Opções - Existem muitas opções IPv4 que podem ou não ser aplicadas. Para mais detalhes, leia o RFC completo especificamente páginas 15 - 22
No final do cabeçalho, o datagram é acolchoado com 0's até terminar com um limite de 32 bits

Resumo da RFC

Como com todos os RFC's este RFC requer que qualquer indivdual que implementa o IP datagram alinha-se com o padrão de tal forma que qualquer parte pode interagir com o datagram em diversos sistemas. Na Secção 3, o esquema de tratamento IPv4 é discutido em comprimento como são as funções resumidas acima. Em relação ao IPv4 este RFC define tamanhos de rede Classe A, B e C. Classe A aloca 7 bits para rede e 24 bits para hosts. Classe B aloca 14 bits para rede e 16 bits para hosts. Classe C aloca 21 bits para rede e 8 bits para hosts. Além de abordar os esquemas, as funções específicas de fragmentação e reassemblagem de dados são discutidas em grande detalhe no âmbito da RFC. Especificando que algumas opções podem ou não ser incluídas quando um pacote está fragmentado.

Referendo-se a um statment anterior sobre a implementação do IP Datagram, o RFC também dá exemplos sobre o que deve ser apresentado aos protocolos de camada superior para elementos de configuração para facilitar uma comunicação e configuração mais fácil entre sistemas. Estes elemenets são os mesmos elementos usados para construir o datagram.