RFC 791 - Internet Protocol - Summary

Også tilgjengelig på:

RFC 791 ble skrevet i 1981 for DARPA (Defense Advanced Research Projects Agency) av Information Sciences Institute University of Southern California. Dokumentet er delt inn i tre deler, Introduksjon, Oversikt og spesifikasjoner. Selv om introduksjonen og oversikten har veldig god informasjon, vil dette sammendraget fokusere på spesifikasjonene, men vil markere few-seksjoner fra oversikten.

Topptekst

Som sett i Frames and Packets-artikkelen på dette nettstedet ser IP-headeren 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)

Hoveddetaljer

Som du kan se dataprogrammet inneholder flere elementer. Funksjonen for hvert element er:

Versjon - RFC 791 refererer spesielt til versjon 4
Internet header Lengde (IHL) - Informerer recieving systemer lengden på hodet og når data starter
Type Service (TOS) - Denne 8 bits verdien brukes til kvalitet på tjenesten.
- bit 0-2 er for precedence
  - 000 - Rutine
  - 001 - Prioritet
  - 010 - Umiddelbart
  - 011-Flash
  - 100 - Flash Overstyr
  - 101 - CRITIC/ECP
  - 110 - Internett-kontroll
  - 111 - Nettverkskontroll
- bit 3 er for normal forsinkelse (0) eller lav forsinkelse (1)
- bit 4 er for normal gjennomstrømning (0) eller høy gjennomstrømning (1)
- bit 5 er for normal pålitelighet (0) eller høy pålitelighet (1)
- Når RFC 791 ble skrevet bit 6 og 7 hvor reservert for fremtidig bruk
Total lengde - Er den totale lengden på datagrammet i byte inntil 65535 okteter. Et system må imidlertid kunne akseptere minst 567 oktetter.
Identifikasjon - Brukes i re-assemble fragmenterte datagram
Flagg - brukt med datagram fragmentering
- bit 0 er reservert og må være 0
- bit 1 hvis satt til 0 tillater et datagram å bli fragementert. Hvis satt til 1 kan datagram ikke fragmenteres
- bit 2 dersom satt til 0 indikert den siste fragement. Hvis satt til 1 flere fragmenter kommer
Fragment Offset - forteller systemene som utfører datagramfragementering hvor det kan fragmentere
Tid til å leve - indikert hvor lenge datagrammet kan vare på nettverket. Hvis den når 0 må datagrammet kastes
Protokol - angir den neste nivåprotokollen som brukes i datagrammet
Header Checksum - Validerer datagrammet hvert punkt gjennom nettverket
Adresse - 32 bits
Destinasjon Adresse - 32 bits
Alternativer - Det er mange IPv4-alternativer som kan eller ikke kan brukes. For ytterligere detaljer, les hele RFC spesifikt side 15 - 22
I slutten av overskriften er datagrammet polstret med 0 til det ender på en 32-bits grense

RFC-sammendrag

Som med alle RFC-er krever denne RFC at alle indivduelle som implementerer IP-datagrammet, tilpasser seg standarden slik at alle parter kan samhandle med datagrammet på ulike systemer. I avsnitt 3 diskuteres IPv4-adresseringsskjemaet i lengden som de funksjoner som er oppsummert ovenfor. I forhold til IPv4 definerer denne RFC klasse A, B og C nettverksstørrelser. Klasse A tildeler 7 biter for nettverk og 24 biter for verter. Klasse B tildeler 14 biter for nettverk og 16 biter for verter. Klasse C tildeler 21 biter for nettverk og 8 biter for verter. I tillegg til å adressere ordninger diskuteres de spesifikke funksjonene til datagramfragmentering og ommontering i stor detalj i RFC. Angi at noen alternativer kan eller ikke kan inkluderes når en pakke er fragmentert.

Referer tilbake til en tidligere statement om å implementere IP-datagrammet, gir RFC også eksempler på hva som skal presenteres til øvre lagprotokoller for konfigurasjonselementer for å forenkle en lettere kommunikasjon og konfigurasjon mellom systemer. Disse elemenets er de samme elementene som brukes til å konstruere datagrammet.