RFC 791 - Internet Protocol - Summary

Fås også i:

RFC 791 blev skrevet i 1981 for DARPA (Defense Advanced Research Projects Agency) af Information Sciences Institute University of Southern California. Dokumentet er opdelt i tre afsnit, Introduktion, Oversigt og Specifikationer. Selv om Introduktion og Oversigt har meget gode oplysninger vil dette resumé fokusere på specifikationerne, men vil fremhæve et par afsnit fra overblikket.

Hoveder

Som det ses i Frames og Packets artiklen på dette websted IP header ligner:

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-detaljer

Som du kan se datagrammet indeholder flere elementer. Funktionen for hvert element er:

Version - RFC 791 refererer specifikt til version 4
Internet Header Længde (IHL) - Informerer recipientsystemer længden af header og når data begynder
Service type (TOS) - Denne 8 bit værdi bruges til kvalitet af service.
- bit 0-2 er for Precedence
  - 000 - Rutine
  - 001 - Prioritering
  - 010 - Øjeblikkelig
  - 011 - Flash
  - 100 - Flash Override
  - 101 - CRITIC / ECP
  - 110 - Internetkontrol
  - 111 - Netværkskontrol
- bit 3 er for Normal forsinkelse (0) eller lav forsinkelse (1)
- bit 4 er for normal gennemstrømning (0) eller høj gennemstrømning (1)
- bit 5 er for normal pålidelighed (0) eller høj pålidelighed (1)
- Når RFC 791 blev skrevet bit 6 og 7 hvor reserveret til fremtidig brug
Samlet længde - er den samlede længde af datagrammet i bytes op til 65535 octetter. Et system skal dog kunne acceptere mindst 567 oktots.
Identifikation - Anvendes i gensamling af fragmenterede datagre
Flag - bruges med datagram fragmentering
- bit 0 er reserveret og skal være 0
- bit 1 hvis indstillet til 0 tillader et datagram at blive fragmenteret. Hvis indstillet til 1 kan datagrammet ikke fragmenteres
- bit 2 hvis indstillet til 0 indikerede den sidste friktion. Hvis sat til 1 flere fragmenter er på vej
Fragment Offset - Fortæller de systemer, der udfører datagramfragementet, hvor det kan fragmentere
Tid til at leve - Indiceret hvor længe datagrammet kan fortsætte på netværket. Hvis det når 0, skal datagrammet kasseres
Protokol - Angiver den næste niveauprotokol, der anvendes i datagrammet
Header Checksum - Validerer datagrammet på hvert punkt gennem netværket
Kildeadresse - 32 bit
Bestemmelsesadresse - 32 bit
Indstillinger - Der er masser af IPv4 muligheder, der kan eller ikke kan anvendes. For yderligere oplysninger læs den fulde RFC specifikt side 15 - 22
I slutningen af headeren er datagrammet polstret med 0 'er indtil det ender på en 32 bit hoppet

RFC-resumé

Som med alle RFC 'er denne RFC kræver, at enhver indivdual, der gennemfører IP datagram tilpasse sig standarden, således at enhver part kan interagere med datagram på forskellige systemer. I afsnit 3 drøftes IPv4-adresseringsskemaet i lang tid ligesom de ovenfor opsummerede funktioner. I forbindelse med IPv4 definerer denne RFC klasse A, B og C netværksstørrelser. Klasse A tildeler 7 bit til netværk og 24 bit til værter. Klasse B tildeler 14 bit til netværk og 16 bit til værter. Klasse C tildeler 21 bit til netværk og 8 bit til værter. Ud over at behandle ordninger de specifikke funktioner af datagram fragmentering og omsamling er drøftet i detaljer inden for RFC. Angivelse af, at nogle muligheder kan eller ikke kan være inkluderet, når en pakke er fragmenteret.

Afviser tilbage til en tidligere statement om gennemførelse af IP Datagram RFC også giver eksempler på, hvad der skal præsenteres for øvre lag protokoller for konfigurationselementer til at lette kommunikation og konfiguration mellem systemer. Disse grundstoffer er de samme elementer, der bruges til at konstruere datagrammet.