RFC 791 został napisany w 1981 roku dla DARPA (Defense Advanced Research Projects Agency) przez Instytut Informacji Uniwersytetu Południowej Kalifornii. Dokument jest podzielony na trzy sekcje, Wprowadzenie, Przegląd i Specyfikacje. Chociaż we wstępie i przeglądzie zawarto bardzo dobre informacje, niniejsze streszczenie skupi się na specyfikacjach, ale podkreśli kilka sekcji z przeglądu.

Nagłówek

Jak widać w artykule Ramki i Pakiety na tej stronie nagłówek IP wygląda jak:

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)

Szczegóły nagłówka

Jak widać, datagram zawiera kilka elementów. Funkcja dla każdego elementu to:

Wersja - RFC 791 odnosi się konkretnie do wersji 4
Długość nagłówka Internetu (IHL) - Informuje systemy odbiorcze o długości nagłówka i momencie rozpoczęcia danych
Rodzaj usługi (TOS) - Ta 8-bitowa wartość jest używana do jakości usługi.
- bit 0-2 są dla prewencji
  - 000 - Rutyna
  - 001 - Priorytet
  - Ekspozycje wobec rządów centralnych i banków centralnych
  - 011 - Flash
  - 100 - Flash Override
  - 101 - CRITIC / ECP
  - 110 - Kontrola sieci
  - 111 - Kontrola sieci
- bit 3 jest dla zwykłego opóźnienia (0) lub niskiego opóźnienia (1)
- bit 4 jest dla normalnej przepustowości (0) lub wysokiej przepustowości (1)
- bit 5 jest dla normalnej niezawodności (0) lub wysokiej niezawodności (1)
- Kiedy RFC 791 został napisany bit 6 i 7 gdzie zarezerwowane do przyszłego użytku
Długość całkowita - Jest to całkowita długość datagramu w bajtach do 65535 oktetów. Jednakże system musi być w stanie zaakceptować co najmniej 567 oktetów.
Identyfikacja - stosowany w montowaniu rozdrobnionych danych
Flagi - używane z rozdrobnieniem datagramu
- bit 0 jest zarezerwowany i musi być 0
- bit 1 jeśli ustawiony na 0 pozwala na rozdrobnienie datagramu. Jeśli ustawiono na 1, nie można rozdrobnić datagramu
- bit 2 jeśli ustawiony na 0 wskazuje ostatnie pęknięcie. Jeśli ustawione na 1 więcej fragmentów nadchodzą
Fragment Offset - Opowiada o systemach wykonujących fragementację datagramową, gdzie może fragmentować
Czas na życie - Wskazano, jak długo datagram może trwać w sieci. Jeśli osiągnie 0, datagram należy wyrzucić
Protokół - Wskazuje protokół następnego poziomu stosowany w datagramie
Header Checksum - waliduje bagram danych w każdym punkcie sieci
Adres źródłowy - 32 bity
Adres docelowy - 32 bity
Opcje - Istnieje wiele opcji IPv4, które mogą lub nie mogą być stosowane. Więcej szczegółów na stronie 15 - 22
Na końcu nagłówka datagram jest dodawany z 0, dopóki nie skończy się na 32 bitowej odcieni

Podsumowanie RFC

Podobnie jak w przypadku wszystkich RFC, RFC wymaga, aby każdy niepodzielny podmiot, który wdraża datagram IP, był zgodny ze standardem, tak aby każda ze stron mogła współdziałać z datagramem na różnych systemach. W sekcji 3 schematy adresowe IPv4 są omawiane na długość, podobnie jak funkcje podsumowane powyżej. W odniesieniu do IPv4 RFC określa rozmiary sieci klasy A, B i C. Klasa A przydziela 7 bitów dla sieci i 24 bitów dla hostów. Klasa B przydziela 14 bitów dla sieci i 16 bitów dla hostów. Klasa C przydziela 21 bitów dla sieci i 8 bitów dla hostów. Oprócz podejścia do programów szczegółowe funkcje rozdrobnienia i ponownego gromadzenia danych są przedmiotem dyskusji w ramach RFC. Określanie, że niektóre opcje mogą lub nie mogą być włączone, gdy pakiet jest rozdrobniony.

Refering back to a previous statut about implementation the IP Datagram the RFC also supposes about what should be presented to upper layer protocols for configuration elements to facilize a facility communication and configuration between systems. Elemenety te są tymi samymi elementami używanymi do budowy datagramu.