RFC 791 - Internet Protocol - Summary

RFC 791 estis skribita en 1981 por DARPA (Defense Advanced Research Projects Agency) fare de la Information Sciences Institute University of Southern California (Informsciencoj Instituto Universitato de Suda Kalifornio). La dokumento estas rompita en tri sekciojn, Enkondukon, Superrigardon, kaj Specifojn. Kvankam la Enkonduko kaj Superrigardo havas tre bonajn informojn tiu resumo fokusos sur la specifoj sed elstarigas afew sekciojn de la superrigardo.

Ĉefa titolo

Kiel vidite en la Frames kaj Packets artikolo en tiu ejo la IP-kapo aspektas kiel:

Pliaj informoj

Kiel vi povas vidi la datumgramon enhavas plurajn elementojn. La funkcio por ĉiu elemento estas:

• RFC 791 specife rilatas al versio 4
• Internet Header Length (IHL) - Informas la reciferajn sistemojn la longo de la titolo kaj kiam datenoj komenciĝas
• Tipo de servo (TOS) - Tiu 8 pecvaloro estas uzita por kvalito de servo.
  • 0-2 estas antaŭĝojo
    • 000 - Routine
    • 001 - Antaŭeco
    • 010 - Immediate
    • 011 - Flash
    • 100 - Flash Override
    • 101 - CRITIC/ECP
    • 110 - Internetwork Control
    • 111 - Reta Kontrolo
  • 3 estas por normala prokrasto (0) aŭ malalta prokrasto (1)
  • peceto 4 estas por normala trairo (0) aŭ Alta trairo (1)
  • proksimume 5 estas por normala fidindeco (0) aŭ alta fidindeco (1)
  • Kiam RFC 791 estis skribita iomete 6 kaj 7 kie rezervite por estonta uzo
• Totala Length - La totala longo de la datengramo en bajtoj ĝis 65535 oktetoj. Tamen, sistemo povas akcepti minimumon de 567 oktetoj.
• Identigo - Uzita en re-asemble fragmentigitaj datengramoj
• Flagoj - uzitaj kun datengrama fragmentiĝo
  • 0 estas rezervita kaj devas esti 0
  • 1 se aro al 0 permesas datengramon esti malfortigita. Se metite al 1 la datengramo ne povas esti fragmentigita
  • 2 Se aro al 0 indikis la lastan malfortigon. Se vi havas 1 pliajn fragmentojn
• Fragment Offset - Tells la sistemoj elfarantaj la datengraman malfortigon kie ĝi povas fragmentiĝi
• Tempo por vivi - dediĉite kiom longa la datumgramo povas daŭri sur la reto. Se ĝi atingas 0 la datumgramon devas esti forĵetita
• Protokolo - Indikas la venontan nivelprotokolon uzitan en la datenoj
• Header Checksum - Validigas la datumgramon ĉe ĉiu punkto tra la reto
• Fonto Adreso: 32 bitoj
• Destination Address - 32 bitoj
• Opcioj - Ekzistas multaj IPv4 opcioj kiuj povas aŭ eble ne estas uzitaj. Por kromaj detaloj bonvolu legi la plenan RFC specife paĝon 15-22
• Ĉe la fino de la kapo, la datengramo estas remburita kun 0 ĝis ĝi finiĝas sur 32 peceto ligita

RFC resumo

Ĉar kun tiu de ĉiu RFC tiu RFC postulas ke ĉiu indiafan kiu efektivigas la IP-datenojngram akordionon kun la normo tia ke ĉiu partio povas interagi kun la datengramo sur diversspecaj sistemoj. En sekcio 3 la IPv4 traktanta skemon estas diskutita en longo kiel estas la funkcioj resumitaj supre. Rilate al IPv4 tiu RFC difinas Class A, B, kaj C-retgrandecojn. Klaso A asignas 7 bitojn por reto kaj 24 bitoj por gastigantoj. Class B asignas 14 pecojn por reto kaj 16 bitoj por gastigantoj. Class C asignas 21 bitojn por reto kaj 8 bitoj por gastigantoj. Aldone al traktado de kabaloj la specifaj funkcioj de datengrama fragmentiĝo kaj re-asembleo estas diskutitaj en granda detalo ene de la RFC. Spektanta ke kelkaj opcioj povas aŭ eble ne estas inkluditaj kiam pakumo estas fragmentigita.

Rilatante reen al antaŭa statment pri efektivigado de la IP Datagram la RFC ankaŭ donas ekzemplojn pri kio devus esti prezentita al supraj tavolprotokoloj por konfiguracioelementoj por rapidigi pli facilan komunikadon kaj konfiguracion inter sistemoj. Tiuj elemeretoj estas la samaj elementoj uzitaj por konstrui la datengramon.