RFC 791 - Internet Protocol - Summary

Tamén dispoñible en:

O RFC 791 foi escrito en 1981 para DARPA (Axencia de Proxectos de Investigación Avanzada en Defensa) polo Instituto de Ciencias da Información da Universidade do Sur de California. O documento divídese en tres seccións: Introdución, Visión xeral e especificacións. Aínda que a Introdución e Visión xeral teñen moi boa información, este resumo centrarase nas especificacións, pero destacará as seccións xerais.

Cabeceira

Como se ve no artigo Frames and Packets neste sitio a cabeceira IP parece:

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)

Detalles de cabeceira

Como podedes ver, o conxunto contén varios elementos. A función de cada elemento é:

RFC 791, versión 4
Lonxitude do encabezado de Internet (IHL) - Informa os sistemas de recepción da lonxitude do encabezado e cando os datos comezan
Tipo de servizo (TOS) - Este valor de 8 bits é usado para a calidade do servizo.
- bit 0-2 para precedencia
  - 000 - Rutina
  - 001 Prioridade
  - 010 - inmediata
  - 011 - Flash
  - Baixar Flash Override
  - 101 - CRITIC/ECP
  - 110 - Control de Internet
  - 111 Control de rede
- bit 3 é para demora normal (0) ou baixa demora (1)
- bit 4 é para uso normal (0) ou superior rendemento (1)
- bit 5 é para a fiabilidade normal (0) ou alta fiabilidade (1)
- Cando o RFC 791 foi escrito bit 6 e 7 para uso futuro
Duración total - É a lonxitude total do datagrama en bytes ata 65535 octets. Un sistema debe ser capaz de aceptar un mínimo de 567 octets.
Identificación - Usado para reasar datagramas fragmentados
Bandeiras usadas con fragmentación de datagramas
- 0 está reservado e debe ser 0
- bit 1 se 0 permite que o datagrama sexa fragmentado. Se o datagrama 1 non pode ser fragmentado
- bit 2 se 0 indica o último fragmento. Se aparece un fragmento máis
Fragment Offset - Explica os sistemas que realizan a fragmentación de datagrama onde pode fragmentar
Tempo para vivir - Indica canto tempo pode persistir o datagrama na rede. Se chega a 0, o datagrama debe ser descartado
Protocolo: indica o protocolo de seguinte nivel utilizado no datagrama
Checksum - Valida o datagrama en cada punto a través da rede
Dirección: 32 bits
Dirección: 32 bits
Opcións - Hai moitas opcións de IPv4 que poden ou non ser implementadas. Para máis detalles, lea o RFC completo na páxina 15 - 22
Ao final da cabeceira, o datagrama está atado con 0 ata que remata cun límite de 32 bits

RFC Resumo

Do mesmo xeito que todo RFC, este RFC require que calquera individual que implemente o datagrama IP aliñado co estándar de tal forma que calquera parte poida interactuar co datagrama en diferentes sistemas. Na sección 3 o esquema de enderezos IPv4 é discutido en lonxitude como son as funcións resumidas anteriormente. En relación co IPv4 este RFC define os tamaños de rede de clase A, B e C. Clase A asignan 7 bits para rede e 24 bits para hosts. Clase B: 14 bits para rede e 16 bits para hosts. Clase C: 21 bits para rede e 8 bits para hosts. Ademais de abordar os esquemas, as funcións específicas de fragmentación de datagramas e re-. son discutidos en gran detalle no RFC. Especificar que algunhas opcións poden ou non ser incluídas cando un paquete está fragmentado.

Referíndose a un estado anterior sobre a aplicación do Datagram IP, o RFC tamén ofrece exemplos sobre o que debe ser presentado aos protocolos de capa superior para os elementos de configuración para facilitar unha comunicación e configuración máis fácil entre sistemas. Estes elémenos son os mesmos elementos utilizados para construír o datagrama.