RFC 791 - Internet Protocol - Summary

Även tillgänglig på:

RFC 791 skrevs 1981 för DARPA (Defense Advanced Research Projects Agency) av Information Sciences Institute University of Southern California. Dokumentet delas in i tre avsnitt, Introduktion, översikt och specifikationer. Även om introduktionen och översikten har mycket bra information kommer denna sammanfattning att fokusera på specifikationerna men kommer att belysa afew sektioner från översikten.

Header

Som framgår av artikeln Frames and Packets på denna webbplats ser IP-rubriken ut som:

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)

Huvuddetaljer

Som du kan se innehåller datagrammet flera element. Funktionen för varje element är:

Version - RFC 791 hänvisar specifikt till version 4
Internet Header Längd (IHL) - Informerar återvinningssystemens längd och när data börjar
Typ av service (TOS) - Detta 8-bitars värde används för servicekvalitet.
- bit 0-2 är för Precedence
  - 000 - Rutin
  - 001 - Prioritet
  - 010 - Omedelbart
  - 011 - Flash
  - 100 - Flash Override
  - 101 - CRITIC/ECP
  - 110 - Internetwork Control
  - 111 - Nätverkskontroll
- bit 3 är för normal försening (0) eller låg försening (1)
- bit 4 är för normal genomströmning (0) eller hög genomströmning (1)
- bit 5 är för normal tillförlitlighet (0) eller hög tillförlitlighet (1)
- När RFC 791 skrevs 6 och 7 där den reserverades för framtida användning
Total längd - Är den totala längden på datagrammet i byte upp till 65535 oktets. Ett system måste dock kunna acceptera minst 567 oktets.
Identifiering - Används i återmontering av fragmenterade datagram
Flaggor - används med datagramfragmentering
- bit 0 är reserverad och måste vara 0
- bit 1 om den är inställd på 0 tillåter ett datagram att fragmenteras. Om inställt på 1 kan datagrammet inte fragmenteras
- bit 2 om inställd på 0 indikerade den sista fragmentet. Om inställt på ytterligare 1 fragment kommer
Fragment Offset - Berättar system som utför datagram fragmentering där det kan fragmentera
Dags att leva - Anger hur länge datagrammet kan kvarstå i nätverket. Om det når 0 måste datagrammet kasseras
Protokoll - Indikerar nästa nivåprotokoll som används i datagrammet
Header Checksum - validerar datagrammet vid varje punkt genom nätverket
Källa Adress - 32 bitar
Destination Adress - 32 bitar
Alternativ - Det finns massor av IPv4 alternativ som kan eller inte kan tillämpas. För ytterligare detaljer läs hela RFC specifikt sidan 15 - 22
I slutet av rubriken är datagrammet vadderat med 0: s tills det slutar på en 32 bit gräns

RFC sammanfattning

Som med alla RFC: s kräver denna RFC att alla indivdualer som implementerar IP-datagrammet i linje med standarden så att någon part kan interagera med datagrammet på olika system. I avsnitt 3 diskuteras IPv4-adresseringsschemat i längd som de funktioner som sammanfattas ovan. I förhållande till IPv4 definierar denna RFC klass A, B och C-nätsstorlekar. Klass A fördelar 7 bitar för nätverk och 24 bitar för värdar. Klass B tilldelar 14 bitar för nätverk och 16 bitar för värdar. Klass C tilldelar 21 bitar för nätverk och 8 bitar för värdar. Förutom att hantera system diskuteras de specifika funktionerna i datagramfragmentering och ommontering i detalj inom RFC. Ange att vissa alternativ kan eller inte kan inkluderas när ett paket är fragmenterat.

Att återgå till en tidigare statistik om implementering av IP Datagram ger också exempel på vad som ska presenteras för övre lagerprotokoll för konfigurationselement för att underlätta en enklare kommunikation och konfiguration mellan system. Dessa elemenets är samma element som används för att konstruera datagrammet.