RFC

RFC: 791
INTERNET PROTOCOL
(Protocolo Internet)
DARPA INTERNET PROGRAM
ESPECIFICACION del PROTOCOLO
Septiembre 1981
(Traduccin al castellano: Mayo 1999)
(Por: Pedro J. Ponce de Len <pjleon@arrakis.es>)
preparado para
Defense Advanced Research Projects Agency
Information Processing Techniques Office
1400 Wilson Boulevard
Arlington, Virginia 22209
por
Information Sciences Institute
University of Southern California
4676 Admiralty Way
Marina del Rey, California 90291
J. Postel
RFC 791
[Pg. 1]
Protocolo Internet
Septiembre 1981
INDICE
PREFACIO ....................................................... iii
1. INTRODUCCION ..................................................... 1
1.1
1.2
1.3
1.4
Motivacin .................................................... 1
mbito ........................................................ 1
Interfaces .................................................... 1
Operacin ..................................................... 2
2. PANORAMA GENERAL ................................................. 5

2.1
2.2
2.3
2.4
Relacin con Otros Protocolos ................................. 9

Modelo de Operacin ........................................... 5
Descripcin de Funciones ...................................... 7
Pasarelas ("Gateways")......................................... 9
3. ESPECIFICACION .................................................. 11
3.1 Formato de Cabecera Internet ................................. 11
3.2 Discusin .................................................... 23
3.3 Interfaces ................................................... 31
APENDICE A: Ejemplos y Escenarios .................................. 34
APENDICE B: Orden de Transmisin de Datos .......................... 39
GLOSARIO ............................................................ 41
REFERENCIAS ......................................................... 45
J. Postel
RFC 791
[Pg. 2]
Protocolo Internet
Septiembre 1981
PREFACIO
Este documento especifica el Protocolo Internet Estndar del DoD
(N.T.: Department of Defense, USA). Este documento est basado en seis
ediciones anteriores de la Especificacin del Protocolo Internet de
ARPA, y el presente texto se basa en gran medida en ellas. Han habido
muchos colaboradores en este trabajo en trminos de conceptos y texto.
Esta edicin revisa aspectos de direccionamiento, tratamiento de
errores, cdigos de opcin, y de las caractersticas de seguridad,
prioridad, compartimientos y manejo de restricciones del protocolo
Internet.
Jon Postel
Editor
J. Postel
RFC 791
[Pg. 3]
Protocolo Internet
RFC: 791
Sustituye a: RFC 760
IENs 128, 123, 111,
80, 54, 44, 41, 28, 26
Septiembre 1981
PROTOCOLO INTERNET
DARPA INTERNET PROGRAM
ESPECIFICACION DE PROTOCOLO
1. INTRODUCCION
1.1. Motivacin
El Protocolo Internet est diseado para su uso en sistemas
interconectados de redes de comunicacin de ordenadores por
intercambio de paquetes. A un sistema de este tipo se le conoce como
"catenet" [1]. El protocolo internet proporciona los medios necesarios
para la transmisin de bloques de datos llamados datagramas desde el
origen al destino, donde origen y destino son hosts identificados por
direcciones de longitud fija. El protocolo internet tambien se
encarga, si es necesario, de la fragmentacin y el reensamblaje de
grandes datagramas para su transmisin a travs de redes de trama
pequea.
1.2. Ambito
El Protocolo Internet est especficamente limitado a proporcionar las
funciones necesarias para enviar un paquete de bits (un datagrama
internet) desde un origen a un destino a travs de un sistema de redes
interconectadas. No existen mecanismos para aumentar la fiabilidad de
datos entre los extremos, control de flujo, secuenciamiento u otros
servicios que se encuentran normalmente en otros protocolos host-ahost. El protocolo internet puede aprovecharse de los servicios de sus
redes de soporte para proporcionar varios tipos y calidades de
servicio.
1.3. Interfaces
Este protocolo es utilizado por protocolos host-a-host en un entorno
internet. Este protocolo utiliza a su vez protocolos de red locales
para llevar el datagrama internet a la prxima pasarela ("gateway") o
host de destino.
Por ejemplo, un mdulo TCP llamara al mdulo internet para tomar un
segmento TCP (incluyendo la cabecera TCP y los datos de usuario) como
J. Postel
RFC 791
[Pg. 4]
Protocolo Internet
Septiembre 1981
la parte de datos de un datagrama internet. El mdulo TCP

suministrara las direcciones y otros parmetros de la cabecera
internet al mdulo internet como argumentos de la llamada. El mdulo
internet creara entonces un datagrama internet y utilizara la

interfaz de la red local para transmitir el datagrama internet.
En el caso de ARPANET, por ejemplo, el mdulo internet llamara a un
mdulo de red local el cual aadira el encabezado 1822 [2] al
datagrama internet creando as un mensaje ARPANET a transmitir al IMP.
La direccin ARPANET sera deducida de la direccin internet por la
interfaz de la red local y sera la direccin de algn host en
ARPANET, el cual podra ser una pasarela a otras redes.
1.4. Operacin
El protocolo internet implementa dos funciones bsicas:
direccionamiento y fragmentacin.
Los mdulos internet usan las direcciones que se encuentran en la
cabecera internet para transmitir los datagramas internet hacia sus
destinos. La seleccin de un camino para la transmisin se llama
encaminamiento.
Los mdulos internet usan campos en la cabecera internet para
fragmentar y reensamblar los datagramas internet cuando sea necesario
para su transmisin a travs de redes de "trama pequea".
El modelo de operacin es que un mdulo internet reside en cada host
involucrado en la comunicacin internet y en cada pasarela que
interconecta redes. Estos mdulos comparten reglas comunes para
interpretar los campos de direccin y para fragmentar y ensamblar
datagramas internet. Adems, estos mdulos (especialmente en las
pasarelas) tienen procedimientos para tomar decisiones de
encaminamiento y otras funciones.
El protocolo internet trata cada datagrama internet como una entidad
independiente no relacionada con ningn otro datagrama internet. No
existen conexiones o circuitos lgicos (virtuales o de cualquier otro
tipo).
El protocolo internet utiliza cuatro mecanismos clave para prestar su
servicio: Tipo de Servicio, Tiempo de Vida, Opciones, y Suma de
Control de Cabecera.
El Tipo de Servicio se utiliza para indicar la calidad del servicio
deseado. El tipo de servicio es un conjunto abstracto o generalizado
de parmetros que caracterizan las elecciones de servicio presentes en
las redes que forman Internet. Esta indicacin de tipo de servicio
J. Postel
RFC 791
[Pg. 5]
Protocolo Internet
Septiembre 1981
ser usada por las pasarelas para seleccionar los parmetros de

transmisin efectivos para una red en particular, la red que se
utilizar para el siguiente salto, o la siguiente pasarela al

encaminar un datagrama internet.
El Tiempo de Vida es una indicacin de un lmite superior en el
periodo de vida de un datagrama internet. Es fijado por el remitente
del datagrama y reducido en los puntos a lo largo de la ruta donde es
procesado. Si el tiempo de vida se reduce a cero antes de que el
datagrama llegue a su destino, el datagrama internet es destrudo.
Puede pensarse en el tiempo de vida como en un plazo de
autodestruccin.
Las Opciones proporcionan funciones de control necesarias o tiles en
algunas situaciones pero innecesarias para las comunicaciones ms
comunes. Las opciones incluyen recursos para marcas de tiempo,
seguridad y encaminamiento especial.
La Suma de Control de Cabecera proporciona una verificacin de que la
informacin utilizada al procesar el datagrama internet ha sido
transmitida correctamente. Los datos pueden contener errores. Si la
suma de control de cabecera falla, el datagrama internet es descartado
inmediatamente por la entidad que detecta el error.
El protocolo internet no proporciona ningn mecanismo de comunicacin
fiable. No existen acuses de recibo ni entre extremos ni entre saltos.
No hay control de errores para los datos, slo una suma de control de
cabecera. No hay retransmisiones. No existe control de flujo.
Los errores detectados pueden ser notificados por medio del Internet
Control Message Protocol (ICMP) (Protocolo de Mensajes de Control de
Internet) [3] el cual est implementado en el mdulo del protocolo
internet.
J. Postel
RFC 791
[Pg. 6]
Protocolo Internet
Septiembre 1981
2. PANORAMA GENERAL
2.1. Relacin con Otros Protocolos
El siguiente diagrama ilustra el lugar del protocolo internet en la
jerarqua de protocolos:
+------+ +-----+ +-----+
+-----+
|Telnet| | FTP | | TFTP| ... | ... |
+------+ +-----+ +-----+
+-----+
| |
|
|
+-----+
+-----+
+-----+
| TCP |
| UDP | ... | ... |
+-----+
+-----+
+-----+
|
|
|
+--------------------------+----+
| Protocolo Internet & ICMP |
+--------------------------+----+
|
+---------------------------+
| Protocolo de la Red Local |
+---------------------------+
Relacin entre Protocolos
Figura 1.
El protocolo Internet interacta por un lado con los protocolos hosta-host de alto nivel y por otro con el protocolo de la red local. En
este contexto una "red local" puede ser una pequea red en un edificio
o una gran red como ARPANET.
2.2. Modelo de Operacin
El modelo de operacin para transmitir un datagrama de una aplicacin
a otra se ilustra en el siguiente escenario:
Suponemos que esta transmisin involucra a una pasarela intermedia.
La aplicacin remitente prepara sus datos y llama a su mdulo
internet local para enviar esos datos como un datagrama y pasa la
direccin de destino y otros parmetros como argumentos de la
llamada.
El mdulo internet prepara una cabecera de datagrama y adjunta los
datos a l. El mdulo internet determina una direccin de la red de
rea local para esta direccin internet, que en este caso es la
direccin de una pasarela.
J. Postel
RFC 791
[Pg. 7]
Protocolo Internet
Septiembre 1981
Enva este datagrama y la direccin de red local a la interfaz de

red local.
La interfaz de red local crea una cabecera de red local, le adjunta
el datagrama y entonces enva el resultado a travs de la red local.
El datagrama llega a un host pasarela encapsulado en la cabecera de
red local, la interfaz de red local desprende esta cabecera y dirige
el datagrama hacia el mdulo internet. El mdulo internet determina
a partir de la direccin internet que el datagrama debe ser
reenviado a otro host en una segunda red. El mdulo internet
determina una direccin de red local para el host de destino. Llama
a la interfaz de red local de esa red para enviar el datagrama.
Esta interfaz de red local crea una cabecera de red local y le

adjunta el datagrama enviando el resultado al host de destino.
En este host de destino la interfaz de red local le quita al
datagrama la cabecera de red local y se lo pasa al mdulo internet.
El mdulo internet determina que el datagrama va dirigido a una
aplicacin en este host. Pasa los datos a la aplicacin en respuesta
a una llamada al sistema, pasando la direccin de origen y otros
parmetros como resultado de la llamada.
Aplicacin
Aplicacin
\
/
Mdulo Internet
Mdulo Internet
Mdulo Internet
\
/
\
/
IRL-1
IRL-1
IRL-2
IRL-2
\
/
\
/
Red Local 1
Red Local 2
Trayectoria de la transmisin
Figura 2
2.3. Descripcin de Funciones
La funcin o propsito del Protocolo Internet es mover datagramas a
travs de un conjunto de redes interconectadas. Esto se consigue
pasando los datagramas desde un mdulo internet a otro hasta que se
alcanza el destino. Los mdulos internet residen en hosts y pasarelas
en el sistema internet. Los datagramas son encaminados desde un mdulo
internet a otro a travs de redes individuales basndose en la
J. Postel
RFC 791
[Pg. 8]
Protocolo Internet
Septiembre 1981
interpretacin de una direccin internet. Por eso, un importante

mecanismo del protocolo internet es la direccin internet.
En el enrutamiento de mensajes desde un mdulo internet a otro, los
datagramas pueden necesitar atravesar una red cuyo tamao mximo de
paquete es menor que el tamao del datagrama. Para salvar esta
dificultad se proporciona un mecanismo de fragmentacin en el
protocolo internet.
Direccionamiento
Se establece una distincin entre nombres, direcciones y rutas [4].
Un nombre indica qu buscamos. Una direccin indica dnde est. Una
ruta indica cmo llegar all. El protocolo internet maneja

principalmente direcciones. Es tarea de los protocolos de mayor
nivel (es decir, protocolos host-a-host o entre aplicaciones) hacer
corresponder nombres con direcciones. El mdulo internet hace
corresponder direcciones de internet con direcciones de red local.
Es tarea de los procedimientos de menor nivel (es decir, redes
locales o pasarelas) realizar la correspondencia entre direcciones
de red local y rutas.
Las direcciones son de una longitud fija de 4 octetos (32 bits). Una
direccin comienza por un nmero de red, seguido de la direccin
local (llamada el campo "resto"). Hay 3 formatos o clases de
direcciones internet: En la Clase A, el bit ms significativo es 0,
los 7 bits siguientes son la red, y los 24 bits restantes son la
direccin local; en la Clase B, los dos bits ms significativos son
uno-cero ("10"), los 14 bits siguientes son la red y los ltimos 16
bits son la direccin local; en la Clase C, los tres bits ms
significativos son uno-uno-cero ("110"), los 21 bits siguientes son
la red y los 8 restantes son la direccin local.
Se debe tener cuidado al relacionar direcciones internet con
direcciones de red local; un host individual fsicamente hablando
debe ser capaz de actuar como si fuera varios hosts distintos, hasta
el punto de usar varias direcciones internet distintas. Algunos
hosts tendrn tambin varios interfaces fsicos (multi-homing).
Esto quiere decir que se debe establecer algn mecanismo que permita
a un host tener varios interfaces fsicos de red, cada uno de ellos
con varias direcciones lgicas internet.
Se pueden encontrar ejemplos de correspondencias de direcciones en
"Correspondencias de Direcciones" [5].
Fragmentacin
J. Postel
RFC 791
[Pg. 9]
Protocolo Internet
Septiembre 1981
La fragmentacin de un datagrama internet es necesaria cuando ste

se origina en una red local que permite un tamao de paquete grande
y debe atravesar una red local que limita los paquetes a un tamao
inferior para llegar a su destino.
Un datagrama internet puede ser marcado como "no fragmentar". Todo
datagrama internet as marcado no ser fragmentado entre distintas
redes bajo ninguna circunstancia. Si un datagrama internet marcado
como "no fragmentar" no puede ser entregado en su destino sin
fragmentarlo, entonces debe ser descartado.
La fragmentacin, transmisin y reensamblaje a travs de una red
local invisible para el mdulo del protocolo internet se llama

fragmentacin intranet y puede ser utilizada [6].
El procedimiento de fragmentacin y reensamblaje en internet tiene
que ser capaz de dividir un datagrama en un nmero casi arbitrario
de piezas que puedan ser luegos reensambladas. El receptor de los
fragmentos utiliza el campo de identificacin para asegurarse de que
no se mezclan fragmentos de distintos datagramas. El campo posicin
("offset") le indica al receptor la posicin de un fragmento en el
datagrama original. La posicin y longitud del fragmento determinan
la porcin de datagrama original comprendida en este fragmento. El
indicador "ms-fragmentos" indica (puesto a cero) el ltimo
fragmento. Estos campos proporcionan informacin suficiente para
reensamblar datagramas.
El campo identificador se usa para distinguir los fragmentos de un
datagrama de los de otro. El mdulo de protocolo de origen de un
datagrama internet establece el campo identificador a un valor que
debe ser nico para ese protocolo y par origen-destino durante el
tiempo que el datagrama estar activo en el sistema internet. El
mdulo de protocolo de origen de un datagrama completo pone el
indicador "ms-fragmentos" a cero y la posicin del fragmento a
cero.
Para fragmentar un datagrama internet grande, un mdulo de protocolo
internet (p. ej., en una pasarela) crea dos nuevos datagramas
internet y copia el contenido de los campos de cabecera internet del
datagrama grande en las dos cabeceras nuevas. Los datos del
datagrama grande son divididos en dos trozos tomando una resolucin
mnima de 8 octetos (64 bits) (el segundo trozo puede no ser un
mltiplo entero de 8 octetos, pero el primero s debe serlo).
Llamemos al nmero de bloques de 8 octetos en el primer trozo NFB
(Number of Fragment Blocks: Nmero de Bloques del Fragmento). El
primer trozo de datos es colocado en el primer nuevo datagrama
internet y el campo longitud total se establece a la longitud del
primer datagrama. El indicador "ms fragmentos" es puesto a uno. El
J. Postel
RFC 791
[Pg. 10]
Protocolo Internet
Septiembre 1981
segundo trozo de datos es colocado en el segundo nuevo datagrama

internet y el campo longitud total se establece a la longitud del
segundo datagrama. El indicador "ms fragmentos" lleva el mismo
valor que en el datagrama grande. El campo posicin del segundo
nuevo datagrama se establece al valor de ese campo en el datagrama
grande ms NFB.
Este procedimiento puede generalizarse para una n-particin, mejor
que para la divisin en dos partes descrita.
Para ensamblar los fragmentos de un datagrama internet, un mdulo de
protocolo internet (por ejemplo en un host de destino) combina todos

los datagramas internet que tengan el mismo valor en los cuatro
campos: identificacin, origen, destino y protocolo. La combinacin
se realiza colocando el trozo de datos de cada fragmento en su
posicin relativa indicada por la posicin del fragmento en la
cabecera internet de ese fragmento. El primer fragmento tendr
posicin cero, y el ltimo fragmento tendr el indicador "ms
fragmentos" puesto a cero.
2.4. Pasarelas
Las pasarelas implementan el protocolo internet para reexpedir
datagramas entre redes. Las pasarelas tambin implementan el Protocolo
Pasarela a Pasarela (Gateway to Gateway Protocol, GGP) [7] para
coordinar el encaminamiento y otra informacin de control internet.
En una pasarela los protocolos de nivel superior no necesitan ser
implementados y las funciones GGP son aadidas al mdulo IP.
+--------------------------------+
| Protocolo Internet & ICMP & GGP|
+--------------------------------+
|
|
+---------------+ +---------------+
| Red Local | | Red Local |
+---------------+ +---------------+
Protocolos de Pasarela
Figura 3.
J. Postel
RFC 791
[Pg. 11]
Protocolo Internet
Septiembre 1981
3. ESPECIFICACION
3.1. Formato de la Cabecera Internet
A continuacin vemos un resumen del contenido de la cabecera internet.
0
1
2
3
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Versin| IHL | Tipo Servicio |
Longitud Total
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Identificacin
|Flags|
Posicin
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Tiempo de Vida | Protocolo | Suma de Control de Cabecera |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Direccin de Origen
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Direccin de Destino
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Opciones
| Relleno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ejemplo de Cabecera de un Datagrama Internet
Figura 4.
Ntese que cada marca (-) corresponde a una posicin de un bit.
Versin: 4 bits
El campo Versin describe el formato de la cabecera internet. Este
documento describe la versin 4.
IHL: 4 bits
Longitud de la Cabecera Internet (Internet Header Length), es la
longitud de la cabecera en palabras de 32 bits, y por tanto apunta
al comienzo de los datos. Ntese que el valor mnimo para una
cabecera correcta es 5.
Tipo de Servicio: 8 bits
El Tipo de Servicio proporciona una indicacin de los parmetros
abstractos de la calidad de servicio deseada. Estos parmetros se
usarn para guiar la seleccin de los parmetros de servicio reales
al transmitir un datagrama a travs de una red en particular.
Algunas redes ofrecen prioridad de servicio, la cual trata de algn
modo el trfico de alta prioridad como ms importante que el resto
J. Postel
[Pg. 12]
RFC 791
Protocolo Internet
Septiembre 1981
del trfico (generalmente aceptando slo trfico por encima de

cierta prioridad en momentos de sobrecarga). La eleccin ms comn
es un compromiso a tres niveles entre baja demora, alta fiabilidad,
y alto rendimiento.
Bits
Bit
Bit
Bit
0-2: Prioridad.
3: 0 = Demora Normal,
1 = Baja Demora.
4: 0 = Rendimiento Normal , 1 = Alto rendimiento.
5: 0 = Fiabilidad Normal , 1 = Alta fiabilidad.]
Bits 6-7: Reservado para uso futuro.

0
1
2
3
4
5
6
7
+-----+-----+-----+-----+-----+-----+-----+-----+
|
|
|
|
|
|
|
| PRECEDENCIA | D | T | R | 0 | 0 |
|
|
|
|
|
|
|
+-----+-----+-----+-----+-----+-----+-----+-----+
Precedencia
111
110
101
100
011
010
001
000
Control de Red
Control Entre Redes
CRITICO/ECP
Muy urgente (Flash Override)
Urgente (Flash)
Inmediato
Prioridad
Rutina
El uso de las indicaciones de Retraso, Rendimiento y fiabilidad

puede incrementar el coste (en cierto sentido) del servicio. En
muchas redes un mejor rendimiento para uno de estos parmetros
conlleva un peor rendimiento en algn otro. Excepto para casos
excepcionales no se deben establecer ms de dos de estos tres
indicadores.
El tipo de servicio se usa para especificar el tratamiento del
datagrama durante su transmisin a travs del sistema internet. Se
dan ejemplos de relacin entre el tipo de servicio internet y el
servicio real proporcionado por redes como AUTODIN II, ARPANET,
SATNET y PRNET en "Correspondencias de Servicios" [8]
La denominacin de precedencia 'Control de Red' est pensada para
ser usada dentro de una sola red. El uso y control efectivos de este
modo es responsabilidad de cada red. El modo 'Control Entre Redes'
est pensado para su uso exclusivo por parte de generadores de
control de pasarela. Si el uso efectivo de estos modos de
precedencia concierne a una red en particular, es responsabilidad de
J. Postel
RFC 791
[Pg. 13]
Protocolo Internet
Septiembre 1981
esa red controlar el acceso a, y el uso de, esos modos de

precedencia.
Longitud Total: 16 bits
La Longitud Total es la longitud del datagrama, medida en octetos,
incluyendo la cabecera y los datos. Este campo permite que la
longitud mxima de un datagrama sea de 65,535 octetos. Los
datagramas de tal longitud no son prcticos para la mayora de hosts

y redes. Todos los hosts deben estar preparados para aceptar
datagramas de hasta 576 octetos (tanto si llegan completos como en
fragmentos). Se recomienda que los hosts enven datagramas mayores
de 576 octetos slo si tienen la seguridad de que el destinatario
est preparado para aceptarlos.
El nmero 576 se ha seleccionado para permitir que un bloque de
datos de tamao razonable sea transmitido junto a la informacin de
cabecera necesaria. Por ejemplo, este tamao permite que un bloque
de datos de 512 octetos ms 64 octetos de cabecera quepa en un
datagrama . La cabecera internet de tamao mximo son 60 octetos, y
una cabecera internet tpica son 20 octetos, admitiendo as un
margen para cabeceras de protocolos de nivel superior.
Identificacin: 16 bits
Es un valor de identificacin asignado por el remitente como ayuda
en el ensamblaje de fragmentos de un datagrama.
Flags (indicadores): 3 bits
Son diversos indicadores de control.
Bit 0: reservado, debe ser cero.
Bit 1: (DF) No Fragmentar (Don't Fragment) 0 = puede fragmentarse,
1 = No Fragmentar.
Bit 2: (MF) Ms Fragmentos (More Fragments) 0 = ltimo Fragmento,
1 = Ms Fragmentos.
0 1 2
+---+---+---+
| |D|M|
|0|F|F|
+---+---+---+
Posicin del Fragmento: 13 bits
Este campo indica a que parte del datagrama pertenece este
fragmento.
J. Postel
RFC 791
[Pg. 14]
Protocolo Internet
Septiembre 1981
La posicin del fragmento se mide en unidades de 8 octetos (64

bits). El primer fragmento tiene posicin 0.
Tiempo de Vida: 8 bits
Este campo indica el tiempo mximo que el datagrama tiene permitido
permanecer en el sistema internet. Si este campo contiene el valor
cero, entonces el datagrama debe ser destrudo. Este campo es

modificado durante el procesamiento de la cabecera internet. El
tiempo es medido en segundos, pero como todo mdulo que procese un
datagrama debe decrementar el TTL (Time To Live: Tiempo de Vida) al
menos en uno, incluso si procesa el datagrama en menos de un
segundo, se debe pensar en el TTL slo como un lmite superior del
tiempo durante el cual un datagrama puede existir. La intencin es
hacer que los datagramas imposibles de entregar sean descartados, y
limitar el mximo periodo de vida de un datagrama.
Protocolo: 8 bits
Este campo indica el protocolo del siguiente nivel usado en la parte
de datos del datagrama internet. Los valores de varios protocolos
son especificados en "Nmeros Asignados" [9].
Suma de Control de Cabecera: 16 bits
Suma de Control de la cabecera solamente. Dado que algunos campos de
la cabecera cambian (p. ej. el tiempo de vida), esta suma es
recalculada y verificada en cada punto donde la cabecera internet es
procesada.
El algoritmo de la suma de control es:
El campo suma de control es el complemento a uno de 16 bits de la
suma de los complementos a uno de todas las palabras de 16 bits de
la cabecera. A la hora de calcular la suma de control, el valor
inicial de este campo es cero.
Esta es una suma de control fcil de calcular y la evidencia
experimental indica que es adecuada, pero es provisional y puede ser
reemplazada por un procedimiento CRC, dependiendo de la experiencia
ulterior.
Direccin de Origen: 32 bits
La direccin de origen. Ver seccin 3.2.
Direccin de Destino: 32 bits
J. Postel
RFC 791
[Pg. 15]
Protocolo Internet
Septiembre 1981
La direccin de destino. Ver seccin 3.2.

Opciones: variable
Las opciones pueden o no aparecer en los datagramas. Deben ser
implementadas por todos los mdulos IP (host y pasarelas). Lo que es
opcional es su transmisin en cualquier datagrama en particular, no

su implementacin.
En algunos entornos la opcin de seguridad puede ser requerida en
todos los datagramas.
El campo opcin es de longitud variable. Pueden existir cero o ms
opciones. Existen dos casos para el formato de una opcin:
Caso 1: Un slo octeto de tipo-opcin.
Caso 2: Un octeto tipo-opcin, un octeto longitud-opcin y los
octetos correspondientes a los datos de opcin.
El octeto longitud-opcin es la cuenta del octeto tipo-opcin y el
octeto longitud-opcin as como los octetos de datos de opcin.
El octeto tipo-opcin tiene 3 campos
1 bit indicador de copiado,
2 bits clase de opcin,
5 bits nmero de opcin.
El indicador de copiado indica si esta opcin es copiada en todos
los fragmentos al fragmentar.
0 = no copiada
1 = copiada
Las clases de opcin son:
0
1
2
3
=
=
=
=
control
reservado para uso futuro
depuracin y medida
reservado para uso futuro
Se definen las siguientes opciones de internet:

CLASE NUMERO LONGITUD DESCRIPCION
----- ------ -------- ----------0
0
- Fin de la lista de opciones. Esta opcin
ocupa un slo octeto. No tiene octeto de
J. Postel
[Pg. 16]
RFC 791
Protocolo Internet
Septiembre 1981
longitud.
Sin Operacin. Esta opcin ocupa un slo
octeto. No tiene octeto de longitud.
11 Seguridad. Usado para Seguridad,
Compartimentacin, Grupo de Usuario
-
(TCC), y Cdigos de Manejo de Restricciones

compatibles con los requerimientos del
Departamento de Defensa.
var. Encaminamiento de Origen No Estricto
(Loose Source Routing). Usado para encaminar
el datagrama internet en base a la
informacin suministrada por el origen.
var. Encaminamiento de Origen Fijo (Strict
Source Routing). Usado para encaminar el
datagrama internet en base a la informacin
suministrada por el origen.
var. Registrar Ruta (Record Route). Usado para
rastrear la ruta que sigue un datagrama
internet.
4 Identificador de Flujo (Stream ID). Usado
para transportar el identificador de flujo.
var. Marca de Tiempo Internet (Internet
Timestamp)
Definiciones de Opciones Especficas

Fin De La Lista de Opciones
+--------+
|00000000|
+--------+
Tipo=0
Esta opcin indica el final de la lista de opciones. Esta puede
no coincidir con el final de la cabecera internet sgn expresa
la longitud de cabecera internet. Se usa al final de todas las
opciones, no al final de cada opcin, y slo es necesario usarla
si, caso de no hacerlo, el final de las opciones no coincidiera
con el final de la cabecera internet.
Puede ser copiado, introducido o borrado en la fragmentacin, o
por cualquier otra razn.
J. Postel
RFC 791
Sin Operacin
+--------+
|00000001|
[Pg. 17]
Protocolo Internet
Septiembre 1981
+--------+
Tipo=1
Esta opcin puede usarse entre opciones para, por ejemplo,
ajustar el comienzo de una opcin siguiente a una posicin
mltiplo de 32 bits.
Puede ser copiado, introducido o borrado en la fragmentacin, o
por cualquier otra razn.
Seguridad
Esta opcin proporciona a los hosts una forma de enviar
parmetros de seguridad, compartimentacin, manejo de
restricciones y TCC (grupo de usuarios cerrado). El formato de
esta opcin es el siguiente:
+--------+--------+---//---+---//---+---//---+---//---+
|10000010|00001011|SSS SSS|CCC CCC|HHH HHH| TCC |
+--------+--------+---//---+---//---+---//---+---//---+
Tipo=130 Longitud=11
Seguridad (campo S): 16 bits
Especifica uno de entre 16 niveles de seguridad (ocho de los
cuales estn reservados para uso futuro)
00000000
11110001
01111000
10111100
01011110
10101111
11010111
01101011
00110101
10011010
01001101
00100100
00010011
10001001
11000100
11100010
00000000
00110101
10011010
01001101
00100110
00010011
10001000
11000101
11100010
11110001
01111000
10111101
01011110
10101111
11010110
01101011
No Clasificado
Confidencial
EFTO
MMMM
PROG
Restringido
Secreto
Alto Secreto
(Reservado para
(Reservado para
(Reservado para
(Reservado para
(Reservado para
(Reservado para
(Reservado para
(Reservado para
J. Postel
RFC 791
uso
uso
uso
uso
uso
uso
uso
uso
futuro)
futuro)
futuro)
futuro)
futuro)
futuro)
futuro)
futuro)
[Pg. 18]
Protocolo Internet
Septiembre 1981
Compartimentos (Campo C): 16 bits

Cuando la informacin no est compartimentada se usa un valor
de todo ceros. Otros valores para el campo Compartimentos

pueden obtenerse de la Agencia de Inteligencia de Defensa.
Manejo de Restricciones (campo H): 16 bits
Los valores para los marcadores de control y liberacin son
digrafos alfanumricos y estn definidos en el Manual DIAM
65-19 "Marcadores de Seguridad Estndar", de la Agencia de
Inteligencia de Defensa.
Cdigo de Control de Transmisin (Campo TCC): 24 bits
Proporciona un mecanismo para segregar el trfico y definir
comunidades de inters controladas entre diversos
suscriptores. Los valores TCC son trigrafos, se pueden
encontrar en "HQ DCA Code 530".
Debe copiarse al fragmentar. Esta opcin aparece como mximo una
vez en un datagrama.
Ruta de Origen No Estricta y Registrar Ruta
+--------+--------+--------+---------//--------+
|10000011| long. | puntero| datos de ruta |
+--------+--------+--------+---------//--------+
Tipo=131
La opcin de Encaminamiento de Origen No Estricto y Registrar
Ruta ("loose source and record route (LSRR)") proporciona un
mecanismo mediante el cual el origen de un datagrama internet
puede suministrar informacin de encaminamiento que ser usada
por las pasarelas para transmitir el datagrama a su destino, y
para almacenar la informacin de la ruta.
La opcin comienza con el cdigo de tipo de opcin. El segundo
octeto es la longitud de la opcin que incluye al cdigo de tipo
de opcin, al propio octeto de longitud, al octeto con el
puntero y a los (long. - 3) octetos de datos de la ruta. El
tercer octeto es el puntero a los datos de ruta que indica el
octeto en el cual comienza la siguiente direccin de origen a
procesar. El puntero es relativo a esta opcin, y el valor legal
ms pequeo para el puntero es 4.
Los datos de ruta se componen de una serie de direcciones
internet. Cada direccin internet son 32 bits o 4 octetos. Si el
J. Postel
RFC 791
[Pg. 19]
Protocolo Internet
Septiembre 1981
puntero es mayor que la longitud, la ruta de origen est vaca

(y la ruta registrada llena) y el encaminamiento debe basarse en
el campo de la direccin de destino.

Si se ha alcanzado la direccin indicada en el campo direccin
de destino y el puntero no es mayor que la longitud, la
siguiente direccin en la ruta de origen sustituye a la
direccin del campo de direccin de destino, y la direccin de
ruta registrada sustituye a la direccin de origen recin usada,
y se suma cuatro al puntero.
La direccin de ruta registrada es la propia direccin internet
que tiene el mdulo internet en el entorno en el cual el
datagrama est siendo reenviado.
Este procedimiento de sustituir la ruta de origen con la ruta
registrada (si bien est en orden inverso del necesario para ser
usada como ruta de origen) significa que la opcin (y la
cabecera IP en su totalidad) sigue teniendo una longitud
constante a medida que el datagrama progresa a travs de
internet.
Esta opcin es una ruta de origen no estricta porque la pasarela
o IP del host puede utilizar cualquier ruta con cualquier nmero
de pasarelas intermedias para alcanzar la siguiente direccin en
la ruta.
Debe copiarse al fragmentar. Aparece como mximo una vez en un
datagrama.
Ruta de Origen Estricta y Registrar Ruta
+--------+--------+--------+---------//--------+
+--------+--------+--------+---------//--------+
Tipo=137
La opcin de Ruta de Origen Estricta y Registrar Ruta (strict
source and record route (SSRR)) proporciona al origen de un
datagrama internet un medio de suministrar informacin de
encaminamiento a ser usada por las pasarelas al reenviar el
datagrama al destino y para registrar la informacin de la ruta.
puntero y a los (long. - 3) octetos de datos de la ruta. El
J. Postel
RFC 791
[Pg. 20]
Protocolo Internet
Septiembre 1981
octeto en el cual comienza la siguiente direccin de origen a
procesar. El puntero es relativo a esta opcin, y su menor valor

legal es 4.
Los datos de ruta se componen de una serie de direcciones
puntero es mayor que la longitud, la ruta de origen est vaca
(y la ruta registrada llena) y el encaminamiento debe basarse en
el campo de la direccin de destino.
Si se ha alcanzado la direccin indicada en el campo de
direccin de destino y el puntero no es mayor que la longitud,
la siguiente direccin en la ruta de origen sustituye a la
direccin del campo de direccin de destino, y la direccin de
ruta registrada sustituye a la direccin de origen recin usada,
y se suma cuatro al puntero.
La direccin de ruta registrada es la propia direccin internet
del mdulo internet tal y como es en el entorno en el cual el
datagrama est siendo reexpedido.
Este procedimiento de sustituir la ruta de origen con la ruta
registrada (si bien est en orden inverso del necesario para ser
usada como ruta de origen) significa que la opcin (y la
cabecera IP en su totalidad) sigue teniendo una longitud
constante a medida que el datagrama progresa a travs de
internet.
Esta opcin es una ruta de origen estricta porque la pasarela o
el IP del host deben enviar el datagrama directamente a la
siguiente direccin en la ruta de origen slamente a travs de
la red conectada directamente indicada en la siguiente
direccin, para alcanzar la siguiente pasarela o host
especificado en la ruta.
datagrama.
Registrar Ruta
+--------+--------+--------+---------//--------+
+--------+--------+--------+---------//--------+
Tipo=7
La opcin de Registrar Ruta proporciona un mecanismo para
registrar la ruta de un datagrama internet.
J. Postel
RFC 791
[Pg. 21]
Protocolo Internet
Septiembre 1981

puntero y a los (long. - 3) octetos de datos de la ruta.El
octeto en el cual comienza la siguiente area para almacenar una
direccin de ruta. El puntero es relativo a esta opcin, y su
menor valor legal es 4.
Una ruta registrada se compone de una serie de direcciones
puntero es mayor que la longitud, el area de datos de la ruta
registrada esta llena. El host de origen debe construir esta
opcin con una rea de datos de ruta con suficiente espacio para
contener todas las direcciones esperadas. El tamao de la opcin
no cambia al agregar direcciones. El contenido inicial del rea
de datos de ruta debe ser cero.
Cuando un mdulo internet encamina un datagrama, comprueba si la
opcin Registrar ruta est presente. Si lo est, inserta su
propia direccin internet, tal y como se la conoce en el entorno
en el cual el datagrama est siendo transmitido, en la ruta
registrada, comenzando en el octeto indicado por el puntero, e
incrementa el puntero en cuatro.
Si el rea de datos de ruta ya est llena (el puntero sobrepasa
a longitud) el datagrama es transmitido sin insertar la
direccin en la ruta registrada. Si hay algo de espacio pero no
el suficiente para insertar una direccin completa, el datagrama
original es considerado errneo y descartado. En ambos casos se
puede enviar un mensaje de problema de parmetros ICMP al host
de origen [3].
No se copia al fragmentar, va slo en el primer fragmento.
Aparece como mximo una vez en un datagrama.
Identificador de Flujo
+--------+--------+--------+--------+
|10001000|00000010| ID de Flujo |
+--------+--------+--------+--------+
Tipo=136 Longitud=4
Esta opcin proporciona una forma de transportar el
identificador de flujo SATNET de 16 bits a travs de redes que
no soportan el concepto de flujo.
J. Postel
RFC 791
[Pg. 22]
Protocolo Internet
Septiembre 1981
datagrama.
Marca de tiempo Internet
+--------+--------+--------+--------+
|01000100| long. | puntero|oflw|flg|
+--------+--------+--------+--------+
|
direccin internet
|
+--------+--------+--------+--------+
|
Marca de tiempo
|
+--------+--------+--------+--------+
|
.
|
.
.
Tipo = 68
La Longitud de opcin es el nmero de octetos en la opcin
contando los octetos de tipo, longitud, puntero y
desbordamiento/indicadores (oflw/flg, overflow/flags) (mxima
longitud: 40)
El puntero es el nmero de octetos desde el principio de esta
opcin hasta el final de las marcas de tiempo mas uno (es decir,
apunta al octeto de comienzo del espacio para la siguiente marca
de tiempo). El valor legal mnimo es 5. El rea de marca de
tiempo est llena cuando el puntero es mayor que la longitud.
El Desbordamiento (oflw) (4 bits) es el nmero de mdulos IP que
no han podido registrar marcas de tiempo debido a falta de
espacio.
Los valores de los Indicadores (4 bits) son
0 -- Slo marcas de tiempo, almacenadas en palabras de 32 bits
consecutivas,
1 -- cada marca de tiempo es precedida con la direccin
internet de la entidad registradora,
3 -- Los campos de direccin internet estn preespecificados.
Un mdulo IP registra su marca de tiempo slo si su
direccin concuerda con la siguiente direccin internet
especificada.
La Marca de Tiempo es una marca temporal de 32 bits, justificada
a la derecha, en milisegundos desde la medianoche UT. Si el
tiempo no est disponible en milisegundos o no puede darse con
respecto a la medianoche UT, entonces se puede insertar
J. Postel
RFC 791
[Pg. 23]
Protocolo Internet
Septiembre 1981
cualquier tiempo como marca de tiempo, siempre que el bit de

mayor orden sea puesto a uno para indicar el uso de un valor no
estndar.
El host de origen debe construir est opcin con un rea de
datos para la marca de tiempo lo sufucientemente grande para que
quepa toda la informacin de marcas temporales esperada. El
tamao de la opcin no cambia al aadir marcas de tiempo. El
contenido inicial del rea de datos de marcas de tiempo debe ser
cero o pares direccin internet/cero.
Si el rea de datos de marca de tiempo ya est llena (el puntero
sobrepasa a la longitud) el datagrama es transmitido sin
insertar marca de tiempo, pero el contador de desbordamiento es
incrementado en uno.
Si hay algo de espacio pero no el suficiente para insertar una
marca de tiempo completa, o el contador de desbordamiento el
mismo se desborda, el datagrama original es considerado errneo
y descartado. En ambos casos se puede enviar un mensaje de
problema de parmetros ICMP al host de origen [3].
La opcin de marca de tiempo no se copia al fragmentar. Es
transportada slo en el primer fragmento. Aparece como mximo
una vez en un datagrama.
Valor de Relleno: variable
El Valor de Relleno se usa para asegurar que la cabecera internet
ocupa un multiplo de 32 bits. El valor de relleno es cero.
3.2. Discusin
La implementacin de un protocolo debe ser robusta. Cada
implementacin debe estar preparada para interoperar con otras creadas
por diferentes individuos. Aunque el objeto de esta especificacin es
ser explcita acerca del protocolo, existe la posibilidad de que se
produzcan interpretaciones discrepantes. En general, una
implementacin debe ser conservadora en su comportamiento al enviar, y
tolerante al recibir. Es decir, debe tener cuidado de enviar
datagramas bien formados , pero debe aceptar cualquier datagrama que
pueda interpretar (p. ej. no poner pegas a errores tcnicos cuando a
pesar de ello el significado sea claro).
El servicio bsico internet est orientado a datagramas y posibilita
la fragmentacin de datagramas en las pasarelas, teniendo lugar el
reensamblaje en el mdulo internet de destino en el host de destino.
Naturalmente, la fragmentacin y el reensamblaje de datagramas en una
J. Postel
[Pg. 24]
RFC 791
Protocolo Internet
Septiembre 1981
red o mediante acuerdo privado entre las pasarelas de una red est
permitido tambin, dado que esto es transparente a los protocolos
internet y a protocolos de nivel superior. Este tipo de fragmentacin
y reensamblaje transparente se denomina fragmentacin "dependiente de
la red" (o intranet) y no se tratar ms sobre ello aqu.
En las direcciones internet se distingue entre orgenes (fuentes) y
destinos a nivel de host y se proporciona tambin un campo en el
protocolo para ellas. Se ha asumido que cada protocolo proporcionar
los medios para cualquier multiplexado que sea necesario en un host.
Direccionamiento
Para proporcionar flexibilidad en la asignacin de direcciones a
redes y tener en cuenta un gran nmero de redes de pequeo a medio
tamao, la interpretacin del campo direccin est codificada para
especificar un peuqeo nmero de redes con un gran nmero de hosts,
un nmero moderado de redes con un nmero moderado de hosts, y un
gran nmero de redes con un pequeo nmero de hosts. Adems existe
un cdigo de escape para un modo de direccionamiento extendido.
Formatos de direccin:
Bits de mayor
------------------0
10
110
111
orden Formato
Class
------------------------------- ----7 bits de red, 24 bits de host
a
14 bits de red, 16 bits de host b
21 bits de red, 8 bits de host c
cd. escape para modo extendido
Un valor cero en el campo de red indica la red actual. Slo se usa

en ciertos mensajes ICMP. El modo de direccionamiento extendido no
est definido. Ambas caractersticas estn reservadas para uso
futuro.
Los valores efectivos asignados para direcciones de red se dan en
"Nmeros asignados" [9].
La direccin local, asignada por la red local, debe tener en cuenta
que un slo host puede actuar como varios hosts internet distintos.
Es decir, debe existir una correspondencia, entre direcciones de
host internet e interfaces de red/host que permitan que a un
interface le correspondan varias direcciones internet. Se debe tener
en cuenta que un host puede tener varios interfaces fsicos y deba
tratar los datagramas de varios de ellos como si fueran destinados
al mismo host.
La correspondencia entre direcciones internet y direcciones para
J. Postel
[Pg. 25]
RFC 791
Protocolo Internet
Septiembre 1981
ARPANET, SATNET, PRNET y otras redes se describen en

"Correspondencias entre direcciones" [5].
Fragmentacin y Reensamblaje.
El campo de identificacin internet (ID) se usa junto con las
direcciones de origen y destino, y los campos de protocolo, para
identificar fragmentos de datagrama para su reensamblaje.
El bit indicador Ms Fragmentos ("More Fragments") (MF) est a uno
si el datagrama no es el ltimo fragmento. El campo Posicn de
Fragmento ("Fragment Offset") identifica la posicin del fragmento,
relativa al comienzo del datagrama original no fragmentado. Los
fragmentos se miden en unidades de 8 octetos. La estrategia de
fragmentacin est diseada de forma que un datagrama no fragmentado
tiene toda su informacin de fragmentacin a cero (MF = 0, posicin
de fragmento = 0). Si un datagrama internet es fragmentado, su parte
de datos debe ser dividida en mltiplos de 8 octetos.
Este formato permite 2**13 = 8192 fragmentos de 8 octetos cada uno,
para un total de 65,536 octetos. Ntese que esto es consistente con
el campo de longitud total del datagrama (por supuesto, la cabecera
se cuenta en la longitud total y no en los fragmentos).
Cuando tiene lugar la fragmentacin, algunas opciones se copian,
pero otras permanecen slo en el primer fragmento.
Cada mdulo internet debe ser capaz de transmitir un datagrama de 68
octetos sin necesidad de ms fragmentacin. Esto es porque una
cabecera internet puede ser de hasta 60 octetos, y el fragmento
mnimo son 8 octetos.
Todo destino internet debe ser capaz de recibir un datagrama de 576
octetos en una sola pieza o en fragmentos a reensamblar.
Los campos que pueden verse afectados por la fragmentacin incluye
a:
(1)
(2)
(3)
(4)
(5)
(6)
el
el
la
el
el
la
campo opciones
indicador Ms Fragmentos
posicin del fragmento
campo longitud de la cabecera internet
campo longitud total
suma de control de la cabecera
Si el indicador "Don't Fragment" (No Fragmentar) (DF) est a uno,

entonces NO est permitida la fragmentacin de este datagrama, si
bien puede ser descartado. Esto puede utilizarse para prohibir la
J. Postel
RFC 791
[Pg. 26]
Protocolo Internet
Septiembre 1981
fragmentacin en casos donde el host receptor no dispone de

suficientes recursos para reensamblar los fragmentos internet.
Un ejemplo del uso de la caracterstica "Don't Fragment" es aliviar
la carga de un pequeo host. Un pequeo host podra tener un
programa de arranque que acepte un datagrama, lo almacene en memoria
y lo ejecute.
Los procedimientos de fragmentacin y reensamblaje se describen de
forma mucho ms sencilla mediante ejemplos. Los siguientes
procedimientos son oimplementaciones de ejemplo.
Notacin general en los pseudo-programas siguientes: "=<" significa
"menor o igual que", "#" significa "no igual", "=" significa
"igual", "<-" significa "se le asigna". Adems, "x to y" incluye 'x'
y excluye 'y'; por ejemplo, "4 to 7" incluira 4, 5 y 6 (pero no 7).
Un Ejemplo de Procedimiento de Fragmentacin
Al datagrama de tamao mximo que se puede transmitir a travs de
la siguiente red se le llama la unidad de transmisin mxima
(maximun transmission unit (MTU)).
Si la longitud total es menor o igual la unidad de transmisin
mxima entonces pasar este datagrama al siguiente paso en el
procesamiento de datagrama; sino partir el datagrama en dos
fragmentos, siendo el primero de tamao mximo, y el segundo el
resto del datagrama. El primer fragmento es pasado al siguiente
paso en el procesamiento de datagramas, mientras que el segundo
fragmento se pasa otra vez a este procedimiento en caso de ser
todava demasiado grande.
Notacin:
FO - Posicin de Fragmento ("Fragment Offset")
IHL - Long. de la cabecera internet (Internet Header Length)
DF - Indicador No Fragmentar ("Don't Fragment")
MF - indicador Ms Fragmentos ("More Fragment")
TL - Longitud total (Total Length)
OFO - FO Previo ("Old Fragment Offset")
OIHL - IHL Previo
OMF - indicador MF Previo (Old More Fragments)
OTL - Longitud total previa (Old Total Length)
NFB - Nm. de bloques de fragmento
(Number of Fragment Blocks)
MTU - Unidad de transmisin mxima
(Maximum Transmission Unit)
J. Postel
RFC 791
[Pg. 27]
Protocolo Internet
Septiembre 1981
Procedimiento:
SI TL =< MTU ENTONCES
Pasar este datagrama al siguiente paso en el procesamiento
de datagramas.
SINO SI DF = 1 ENTONCES
descartar el datagrama
SINO
Para producir el primer fragmento:
(1) Copiar la cabecera internet original;
(2) OIHL <- IHL; OTL <- TL; OFO <- FO; OMF <- MF;
(3) NFB <- (MTU-IHL*4)/8;
(4) Adjuntar los primeros NFB*8 octetos de datos;
(5) Corregir la cabecera:
MF <- 1; TL <- (IHL*4)+(NFB*8);
Recalcular la Suma de Control;
(6) Pasar este datagrama al siguiente paso en el procesamiento
de datagramas;
Para producir el segundo fragmento:
(7) Copiar de forma selectiva la cabecera internet (algunas
opciones no se copian, ver definiciones de opcin);
(8) Aadir los datos restantes;
(9) Corregir la cabecera:
IHL <- (((OIHL*4)-(long. de opciones no copiadas))+3)/4;
TL <- OTL - NFB*8 - (OIHL-IHL)*4);
FO <- OFO + NFB; MF <- OMF; Recalcular Suma de Control;
(10) Pasar este fragmento al test de fragmentacin; FIN.
En el procedimiento anterior cada fragmento (excepto el ltimo)
fue construdo con el tamao mximo permitido. Otra alternativa
podra producir datagramas menores que el tamao mximo. Por
ejemplo, uno podra implementar un procedimiento de fragmentacin
que dividiera repetidamente los datagramas grandes en dos hasta
que los fragmentos resultantes fueran de menor tamao que el
tamao de la unidad de transmisin mxima.
Un ejemplo de Procedimiento de Reensamblaje
Para cada datagrama el identificador de buffer se calcula como la
concatenacin de los campos de origen, destino, protocolo e
identificacin. Si se trata de un datagrama completo (es decir,
los campos Posicin de Fragmento y Ms Fragmentos son cero),
entonces todos los recursos de reensamblaje asociados con este
identificador de buffer son liberados y el datagrama se pasa al
siguiente paso en el procesamiento de datagramas.
Si no hay a mano otros fragmentos con este identificador de buffer
J. Postel
RFC 791
[Pg. 28]
Protocolo Internet
Septiembre 1981
entonces se asignan recursos de reensamblaje. Los recursos de

reensamblaje consisten en un buffer de datos, un buffer de
cabecera, una tabla de bits de bloque de fragmento, un campo de
longitud total de datos, y un temporizador. Los datos contenidos
en el fragmento se guardan en el buffer de datos de acuerdo con su
posicin de fragmento y longitud y se modifican bits en la tabla
de bits de bloques de fragmento correspondientes a los bloques de
fragmento recibidos.
Si este es el primer fragmento (es decir, la posicin del
fragmento es cero) esta cabecera se guarda en el buffer de
cabecera. Si este es el ltimo fragmento (es decir, su campo Ms
Fragmentos es cero) se calcula la longitud total de los datos. Si
este fragmento completa el datagrama ( lo cual se comprueba
mirando los bits puestos a uno en la tabla de bloques de
fragmento), entonces el datagrama es enviado al siguiente paso en
el procesamiento de datagramas; sino se le asigna al temporizador
el mximo de su valor actual y el valor del campo Tiempo de Vida
de este fragmento; y por ltimo la rutina de reensamblaje devuelve
el control.
Si el temporizador se agota, se liberan todos los recursos de
reensamblaje para este identificador de buffer. El valor inicial
del temporizador es un lmite inferior del tiempo de espera de
reensamblaje. Esto es as porque el tiempo de espera ser
incrementado si el Tiempo de Vida del fragmento recin llegado es
mayor que el valor actual del temporizador, pero no ser
decrementado si es menor. El valor mximo que este temporizador
puede alcanzar es el timepo de vida mximo (aproximadamente 4.25
minutos). La recomendacin actual para el valor inicial del
temporizador es 15 segundos. Este puede variar conforme la
experiencia con este protocolo se acumule. Ntese que la eleccin
del valor de este parmetro est relacionada con la capacidad de
buffer disponible y la velocidad de datos del medio de
transmisin; es decir, la velocidad de datos por el valor del
temporizador es igual al tamao del buffer (p. ej., 10Kb/s X 15s =
150 Kb).
Notacin:
FO
IHL
MF
TTL
NFB
- Posicin del Fragmento ("Fragment Offset")

- Long. de la cabecera internet (Internet Header Length)
- indicador Ms Fragmentos ("More Fragments")
- Timepo de Vida
- Nm. de bloques de fragmento
(Number of Fragment Blocks)
TL - Longitud total (Total Length)
TDL - Longitud total de Datos (Total Data Length)
J. Postel
RFC 791
[Pg. 29]
Protocolo Internet
Septiembre 1981
BUFID - Identificador de buffer (Buffer Identifier)

RCVBT - Tabla de Bits de Fragmentos Recibidos
(Fragment Received Bit Table)
TLB - Lmite Inferior del Temporizador (Timer Lower Bound)
Procedimiento:
(1) BUFID <- origen|destino|protocolo|identificacin;
(2) SI FO = 0 Y MF = 0
(3)
ENTONCES SI est reservado el buffer con BUFID
(4)
ENTONCES liberar todo el reensamblaje para este BUFID;
(5)
Pasar el datagrama al siguiente paso; FIN.
(6)
SINO SI no est reservado el buffer con BUFID
(7)
ENTONCES Asignar recursos de reensamblaje con
BUFID;
TEMPORIZADOR <- TLB; TDL <- 0;
(8)
guardar los datos del fragmento en el buffer de
datos con BUFID desde el octeto FO*8 al octeto
(TL-(IHL*4))+FO*8;
(9)
poner a uno los bits RCVBT desde FO
a FO+((TL-(IHL*4)+7)/8);
(10)
SI MF = 0 ENTONCES TDL <- TL-(IHL*4)+(FO*8)
(11)
SI FO = 0 ENTONCES
guardar cabecera en buffer de cabecera
(12)
SI TDL # 0
(13)
Y todos los bits RCVBT desde 0 a (TDL+7)/8 son uno
(14)
ENTONCES TL <- TDL+(IHL*4)
(15)
Pasar el datagrama al siguiente paso;
(16)
liberar todos los recursos de reensamblaje
para este BUFID; FIN.
(17)
TEMPORIZADOR <- MAX(TEMPORIZADOR,TTL);
(18)
ceder control hasta siguiente fragmento o hasta que
el temporizador se agote;
(19) El temporizador se ha agotado: vaciar todo el reensamblaje
con este BUFID; FIN.
En el caso en que dos o ms fragmentos contengan los mismos datos
tanto idnticamente como por solapamiento parcial, este
procedimiento usar la copia llegada ms recientemente en el
buffer de datos y en el datagrama entregado.
Identificacin
La eleccin del Indentificador de un datagrama est basada en la
necesidad de proporcionar una forma de identificar de forma nica un
datagrama en particular. El mdulo del protocolo que reensambla
fragmentos los evala como pertenecientes al mismo datagrama si
tienen el mismo origen, destino, protocolo e Identificador. De este
J. Postel
RFC 791
[Pg. 30]
Protocolo Internet
Septiembre 1981
modo el remitente debe elegir un Identificador que sea nico para

ese par origen-destino y ese protocolo, y durante el tiempo que el
detagrama (o cualquier fragmento suyo) pueda perdurar en internet.
Parece entonces que un mdulo de protocolo que actue de remitente
necesite mantener una tabla de Identificadores, con una entrada por
cada destino con el que haya comunicado en el ltimo periodo de
mxima duracin de un paquete en internet.
Sin embargo, dado que el campo Identificador permite 65,536 valores
diferentes, algn host puede ser capaz de usar simplemente
identificadores nicos independientemente del destino.
Para algunos protocolos de nivel superior resulta adecuado elegir el
identificador. Por ejemplo, los mdulos de protocolo TCP pueden
retransmitir un segmento TCP idntico, y la probabilidad de una
recepcin correcta se vera ampliada si la retransmisin lleva el
mismo identificador que la transmisin original, ya que se podran
usar fragmentos de cualquiera de los dos datagramas para construir
un segmento TCP correcto.
Tipo de Servicio
El Tipo de servicio (Type Of Service (TOS)) se utiliza para la
seleccin de la calidad del servicio internet. El tipo de servicio
se especifica a travs de los parmetros abstractos de precedencia,
demora, rendimiento, y fiabilidad. Estos parmetros abstractos se
hacen corresponder con parmetros de servicio efectivos de las redes
particulares que el datagrama atraviesa.
Precedencia. Medida independiente de la importancia de este
datagrama.
Demora. La entrega inmediata es importante para datagramas con esta
indicacin.
Rendimiento. Una alta velocidad de datos es importante para
datagramas con esta indicacin.
Fiabilidad. Para datagramas con esta indicacin es importante un
mayor nivel de esfuerzo para asegurar la entrega.
Por ejemplo, La ARPANET tiene un bit de prioridad, y la posibilidad
de elegir entre mensajes "estndar" (tipo 0) y "no controlados"
(tipo 3) (La eleccin entre mensajes de paquete nico o multipaquete
puede considerarse tambin un parmetro de servicio). Los mensajes
no controlados tienden a ser entregados con menos fiabilidad y a

sufrir menos demora. Supngase que un datagrama internet se va a
J. Postel
RFC 791
[Pg. 31]
Protocolo Internet
Septiembre 1981
enviar a travs de ARPANET. Sea el tipo de servicio internet dado

como:
Precendencia: 5
Demora:
0
Rendimiento: 1
Fiabilidad: 1
En este ejemplo, la correspondencia de estos parmetros con aquellos
disponibles para ARPANET sera poner a uno el bit de prioridad de
ARPANET, ya que la precedencia Internet se sita en la mitad
superior de su escala, seleccionar mensajes estndar ya que se han
indicado los requerimientos de rendimiento y fiabilidad y no de
demora. Se dan ms detalles sobre correspondencias de servicio en
"Correspondencias de Servicio ("Service Mappings") [8].
Tiempo de Vida
El tiempo de vida es establecido por el remitente al tiempo mximo
que un datagrama puede estar en el sistema internet. Si el datagrama
permanece en el sistema internet durante ms tiempo que su tiempo de
vida, entonces el datagrama debe ser destrudo.
Este campo debe ser decrementado en cada punto donde se procese para
reflejar el tiempo invertido en procesar el datagrama. Incluso si no
existe informacin local acerca del tiempo realmente empleado, el
campo debe decrementarse en 1. El tiempo es medido en unidades de
segundo (es decir, el valor 1 significa un segundo). Por tanto, el
tiempo de vida mximo son 255 segundos o 4.25 minutos. Como todo
mdulo que procese un datagrama debe decrementar el TTL por lo menos
en uno incluso si lo procesa en menos de un segundo, debe pensarse
en el TTL slo como un lmite superior del tiempo que un datagrama
puede existir. La intencin es hacer que los datagramas que no se
pueden entregar sean descartados, y limitar el mximo periodo de
vida del datagrama.
Algunos protocolos de conexin fiables de alto nivel se basan en la
presuncin de que los datagramas duplicados ms viejos no llegarn
despus de pasar un cierto tiempo. El TTL es para tales protocolos
un medio de tener la seguridad de que su suposicin se cumple.
Opciones
Las opciones son opcionales en cada datagrama, pero obligatorias en
las implementaciones. Es decir, la presencia o ausencia de una
opcin es eleccin del remitente, pero cada mdulo internet debe ser
capaz de analizar cualquier opcin. Puede haber varias opciones
presentes en el campo opcin.
J. Postel
RFC 791
[Pg. 32]
Protocolo Internet
Septiembre 1981
Las opciones pueden no ocupar exactamente un espacio mltiplo de 32

bits. La cabecera debe ser completada con octetos de ceros. El
primero de estos ser interpretado como la opcin fin-de-opciones, y
el resto como el relleno de la cabecera internet.
Todo mdulo internet debe ser capaz de actuar en cada opcin. La
Opcin de Seguridad es obligatoria si se debe atravesar un trfico
clasificado, restringido o compartimentado.
Suma de Control
La suma de control de la cabecera internet es recalculada si la
cabecera es modificada. Por ejemplo, una reduccin del tiempo de
vida, las adiciones o cambios en las opciones internet, o debido a
la fragmentacin. Esta suma de control a nivel internet est pensada
para proteger de errores de transmisin los campos de la cabecera
internet.
Existen algunas aplicaciones donde son aceptables unos pocos errores
en los bits de datos, mientras que los retrasos por retransmisin no
lo son. Si el protocolo internet impusiera la exactitud de datos
tales aplicaciones no podran ser soportadas.
Errores
Los errores en el protocolo internet pueden indicarse mediante los
mensajes ICMP [3].
3.3. Interfaces
La descripcin funcional de interfaces de usuario para IP es, en el
mejor de los casos, ficticia, ya que cada sistema operativo dispondr
de distintos recursos. En consecuencia, debemos advertir a los
lectores que diferentes implementaciones IP pueden tener diferentes
interfaces de usuario. Sin embargo, todas deben proporcionar un cierto
conjunto mnimo de servicios para garantizar que todas las
implementaciones IP pueden soportar la misma jerarqua de protocolos.
Esta seccin especifica las interfaces funcionales obligatorias para
todas las implementaciones IP.
El protocolo internet interacta con la red local por un lado y con un
protocolo de nivel superior o una aplicacin por el otro. En lo que
sigue, el protocolo de nivel superior o aplicacin (o incluso un
programa pasarela) ser llamado el "usuario", dado que es lo que usa
el mdulo internet. Como el protocolo internet es un protocolo de

datagramas, se mantiene un mnimo de memoria o estado entre
transmisiones de datagramas, y cada llamada del usuario al mdulo del
protocolo internet proporciona toda la informacin necesaria para que
J. Postel
RFC 791
[Pg. 33]
Protocolo Internet
Septiembre 1981
el IP ejecute el servicio pedido.

Interface Ejemplo de nivel superior
Las siguientes dos llamadas de ejemplo satisfacen los requisitos de la
comunicacin entre el usuario y el mdulo del protocolo internet ("=>"
significa 'devuelve'):
SEND (src, dst, prot, TOS, TTL, BufPTR, len, Id, DF, opt => result)
donde:
src = direccin de origen
dst = direccin de destino
prot = protocolo
TOS = tipo de servicio
TTL = tiempo de vida
BufPTR = puntero a buffer
len = longitud del buffer
Id = Identificador
DF = No Fragmentar
opt = datos de opcin
result = respuesta
OK = datagrama enviado correctamente
Error = error en los argumentos o error en la red local
Ntese que la precedencia se incluye en el TOS y la
seguridad/compartimiento se pasa como opcin.
RECV (BufPTR, prot, => result, src, dst, TOS, len, opt)
donde:
BufPTR = puntero a buffer
prot = protocolo
result = respuesta
OK = datagrama recibido correctamente
Error = error en los argumentos
len = longitud del buffer
src = direccin de origen
dst = direccin de destino
TOS = tipo de servicio
opt = datos de opcin

Cuando el usuario enva un datagrama, ejecuta la llamada SEND
suministrando todos los argumentos. El mdulo del protocolo internet,
al recibir esta llamada, comprueba los argumentos y prepara y enva el
J. Postel
RFC 791
[Pg. 34]
Protocolo Internet
Septiembre 1981
mensaje. Si los argumentos son vlidos y el datagrama es aceptado por

la red local, la llamada retorna con xito. Si los argumentos no son
correctos, o bien el datagrama no es aceptado por la red local, la
llamada retorna sin xito. En retornos de llamada sin xito, se debe
construir un informe razonable sobre la causa del problema, pero los
detalles de tales informes corresponden a las distintas
implementaciones.
Cuando un datagrama llega al mdulo del protocolo internet desde la
red local, o hay una llamada RECV pendiente del usuario al que va
dirigido o no la hay. En el primer caso, la llamada pendiente es
satisfecha pasando la informacin desde el datagrama al usuario. En el
segundo caso, se notifica al usuario de destino que tiene un datagrama
pendiente. Si el usuario de destino no existe, se devuelve un mensaje
de error ICMP al remitente, y los datos son desechados.
La notificacin de un usuario puede ser a travs de una pseudo
interrupcin o un mecanismo similar, correspondiente al entorno
particular del sistema operativo de la implemetacin.
Una llamada RECV de usuario puede ser inmediatamente satisfecha por un
datagrama pendiente, o bien quedar pendiente hasta que llegue un
datagrama.
La direccin de origen se incluye en la llamada SEND en el caso de que
el host remitente tenga varias direcciones (mltiples conexiones
fsicas o direcciones lgicas). El mdulo internet debe comprobar que
la direccin de origen es una de las direcciones legales de este host.
Una implementacin tambin puede permitir o exigir una llamada al
mdulo internet para indicar interes en o reservar para uso exclusivo
una clase de datagramas (p. ej., todos aquellos con un cierto valor en
el campo protocolo)
Esta seccin caracteriza funcionalmente una interfaz USUARIO/IP. La
notacin utilizada es similar a la mayora de llamadas de funcin de
lenguajes de alto nivel, pero este uso no pretende excluir las
llamadas de sewrvicio tipo 'trap' (p. ej., SVCs, UUOs, EMTs), o
cualquier otra forma de comunicacin entre procesos.
J. Postel
RFC 791
[Pg. 35]
Protocolo Internet
Septiembre 1981
APENDICE A: Ejemplos y Escenarios

Ejemplo 1:
Este es un ejemplo de un datagrama internet con un mnimo de datos:
0
1
2
3
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 5 | Tipo de Serv. |
Long. Total = 21
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Identificacin = 111
|Flg=0| Pos. de Fragmento = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL = 123 | Protocolo = 1 |
suma de control
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
direccin de origen
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
direccin de destino
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
datos
|
+-+-+-+-+-+-+-+-+
Ejemplo de Datagrama Internet
Figura 5.
Ntese que cada divisin representa una posicin de un bit.
Este es un datagrama internet en la versin 4 del protocolo internet;
la cabecera internet consta de 5 palabras de 32 bits, y la longitud
total del datagrama es de 21 octetos. Este datagrama es un datagrama
completo (no un fragmento).
J. Postel
RFC 791
[Pg. 36]
Protocolo Internet
Septiembre 1981
Ejemplo 2:
En este ejemplo, se muestra primero un datagrama internet de tamao
medio (452 octetos de datos), y despus dos fragmentos internet que
podran ser resultado de la fragmentacin de este datagrama si la
transmisin de mximo tamao permitida fuese de 280 octetos.
0
1
2
3
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Long. Total = 472
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Identificacin = 111
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
suma de control
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
direccin de origen
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
direccin de destino
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
datos
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
datos
|
\
\
\
\
|
datos
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
datos
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 6.
J. Postel
RFC 791
[Pg. 37]
Protocolo Internet
Septiembre 1981
Ahora el primer fragmento resultado de dividir el datagrama a los 256

octetos.
0
1
2
3
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Long. Total = 276
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Identificacin = 111
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
suma de control
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
direccin de origen
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
direccin de destino
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
datos
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
datos
|
\
\
\
\
|
datos
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
datos
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ejemplo de Fragmento Internet
Figura 7.
J. Postel
RFC 791
[Pg. 38]
Protocolo Internet
Septiembre 1981
Y el segundo fragmento.
0
1
2
3
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Long. Total = 216
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Identificacin = 111
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
suma de control
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
direccin de origen
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
direccin de destino
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
datos
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
datos
|
\
\
\
\
|
datos
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
datos
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ejemplo de Fragmento Internet
Figura 8.
J. Postel
RFC 791
[Pg. 39]
Protocolo Internet
Septiembre 1981
Example 3:
Aqui se muestra un ejemplo de un datagrama que contiene opciones:
0
1
2
3
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Long. Total = 576
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Identificacin = 111
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
suma de control
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
direccin de origen
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
direccin de destino
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cd. Opc. = x | Long. Opc.= 3 | valor opcin | Cd. Opc. = x |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Long. Opc.= 4 |
valor de opcin
| Cd. Opc. = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cd. Opc. = y | Long. Opc.= 3 | valor opcin | Cd. Opc. = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
datos
|
\
\
\
\
|
datos
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
datos
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 9.
J. Postel
RFC 791
[Pg. 40]
Protocolo Internet
Septiembre 1981
APPENDICE B: Orden de Transmisin de Datos

El orden de transmisin de la cabeceras y los datos descritos en este
documento se resuelve a nivel de octeto. Cuando un diagrama muestra un
grupo de octetos, el orden de transmisin de stos es el orden normal
en el cual se leen en Ingls. Por ejemplo, en el siguiente diagrama
los octetos son transmitidos en el orden en el que van numerados.
0
1
2
3
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
1
|
2
|
3
|
4
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
5
|
6
|
7
|
8
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
9
|
10
|
11
|
12
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Orden de Transmisin de Bytes
Figura 10.
Cuando un octeto representa una cantidad numrica el bit ms a la
izquierda en el diagrama es el bit de mayor orden o bit ms
significativo. Es decir, El bit etiquetado como 0 es el bit ms
significativo. Por ejemplo, el diagrama siguiente representa el valor
170 (decimal).
01234567
+-+-+-+-+-+-+-+-+
|1 0 1 0 1 0 1 0|
+-+-+-+-+-+-+-+-+
Significado de Bits
Figura 11.
De forma similar, cuando un campo multiocteto representa una cantidad

numrica el bit ms a la izquierda de todo el campo es el bit ms
significativo. Cuando una cantidad multi-octeto es transmitida se
transmite primero el octeto ms significativo.
J. Postel
RFC 791
[Pg. 41]
Protocolo Internet
Septiembre 1981
GLOSARIO
1822
BBN Report 1822, "Especificacin de la Interconexin de un

Host y un IMP". La especificacin de la interfaz entre un
host y ARPANET.
ARPANET leader
La informacin de control en un mensaje ARPANET en la interfaz
host-IMP.
mensaje ARPANET
La unidad de transmisin entre un host y un IMP en ARPANET. El
tamao mximo es aproximadamente 1012 octetos (8096 bits).
paquete ARPANET
Una unidad de transmisin usada internamente entre IMPs en
ARPANET. El tamao mximo es aprox. 126 octetos (1008 bits).
Destino
La direccin de destino, un campo de la cabecera internet.
DF
El bit 'Don't Fragment' (No Fragmentar) del campo de

indicadores.
Indicadores (Flags)
Un campo de la cabecera internet con varios indicadores de
control.
Posicin del Fragmento
Posicin del fragmento. Este campo de la cabecera internet
indica a que lugar del datagrama internet pertenece un
fragmento.
GGP
Gateway to Gateway Protocol (Protocolo Pasarela a Pasarela),

el protocolo usado principalmente entre pasarelas para
controlar el encaminamiento y otras funciones de pasarela.
cabecera
Informacin de control al principio de un mensaje, segmento,
datagrama, paquete o bloque de datos.
ICMP
Internet Control Message Protocol (Protocolo de Mensajes de
J. Postel
RFC 791
[Pg. 42]
Protocolo Internet
Septiembre 1981
Control de Internet), implementado en el mdulo internet, el

ICMP es usado de pasarelas a hosts y entre hosts para informar
de errores y hacer sugerencias de encaminamiento.
Identificacin
Un campo de la cabecera internet que almacena el valor
identificador asignado por el remitente como ayuda para
ensamblar los fragmentos de un datagrama.
IHL
El campo de la cabecera internet 'Internet Header Length'

(Longitud de la cabecera internet) es la longitud de la
cabecera internet medida en palabras de 32 bits.
IMP
Interface Message Processor (Procesador de Mensajes de
Interfaz), el intercambiador de paquetes de ARPANET.
Direccin Internet
Una direccin de origen o destino de 4 octetos (32 bits)
formada por un campo de Red y un campo de Direccin Local.
Datagrama internet
La unidad de datos intercambiada entre un par de mdulos
internet (incluye la cabecera internet).
Fragmento internet
Una parte de los datos de un datagrama internet con una
cabecera internet.
Direccin Local
La direccin de un host en una red. La relacin real entre una
direccin local internet con las direcciones de un host en una
red es muy general, permitindose relaciones de muchos a uno.
MF
El indicador 'More-Fragments' (Ms Fragmentos) presente en el
campo indicadores de la cabecera internet.
mdulo
Una implementacin, normalmente en software, de un protocolo u
otro procedimiento.
indicador 'more-fragments'
Un indicador que dice si este datagrama internet contiene el
final de un datagrama internet, presente en el campo
Indicadores de la cabecera internet.
J. Postel
RFC 791
NFB
[Pg. 43]
Protocolo Internet
Septiembre 1981
Number of Fragment Blocks (Nmero de Bloques de Fragmento) en

la parte de datos de un fragmento internet. Es decir, la
longitud de una parte de datos medida en unidades de 8
octetos.
octeto
Un byte de 8 bits.
Opciones
El campo Opciones de la cabecera internet puede contener
varias opciones, y cada una de ellas puede ser de varios
octetos de longitud.
Valor de Relleno (Padding)
El campo Valor de Relleno de la cabecera internet se utiliza
para asegurar que el campo de datos comienza en una direccin
mltiplo de 32 bits. El relleno es cero.
Protocolo
En este documento, un campo de la cabecera internet, el
identificador del protocolo del siguiente nivel superior.
Resto
La parte de direccin local de una direccin internet.
Origen
La direccin de origen, un campo de la cabecera internet.
TCP
Transmission Control Protocol (Protocolo de Control de
Transmisin): Un protocolo host-a-host para comunicacin
fiable en entornos internet.
Segmento TCP
La unidad de datos intercambiada entre dos mdulos TCP
(incluyendo la cabecera TCP).
TFTP
Trivial File Transfer Protocol (Protocolo de Transferencia de
Archivos Trivial): Un sencillo protocolo de transferencia de
archivos construdo sobre UDP).
Tiempo de Vida
Un campo de la cabecera internet que indica el lmite superior
de cunto tiempo puede existir el datagrama.
TOS
J. Postel
RFC 791
[Pg. 44]
Protocolo Internet
Septiembre 1981
Type of Service (Tipo de Servicio)

Longitud Total
El campo de la cabecera Internet 'Longitud Total' es la
longitud del datagrama en octetos, incluyendo cabecera y
datos.
TTL
Time to Live (Tiempo de Vida)
Tipo de Servicio
Un campo de la cabecera internet que indica el tipo (o
calidad) de servicio para este datagrama.
UDP
User Datagram Protocol (Protocolo de Datagrama de Usuario): Un
protocolo a nivel de usuario para aplicaciones orientadas a
transacciones.
Usuario
El usuario del protocolo internet. Este puede ser un mdulo de
protocolo de nivel superior, una aplicacin, o un programa
pasarela.
Versin
El campo Versin indica el formato de una cabecera internet.
J. Postel
RFC 791
[Pg. 45]
Protocolo Internet
Septiembre 1981
REFERENCIAS
[1] Cerf, V., "The Catenet Model for Internetworking", Information
Processing Techniques Office, Defense Advanced Research Projects
Agency, IEN 48, Julio 1978.
[2] Bolt Beranek and Newman, "Specification for the Interconnection of
a Host and an IMP", BBN Technical Report 1822, Revisado Mayo 1978.
[3] Postel, J., "Internet Control Message Protocol - DARPA Internet
Program Protocol Specification", RFC 792, USC/Information Sciences
Institute, Septiembre 1981.
[4] Shoch, J., "Inter-Network Naming, Addressing, and Routing",
COMPCON, IEEE Computer Society, Otoo 1978.
[5] Postel, J., "Address Mappings", RFC 796, USC/Information Sciences
[6] Shoch, J., "Packet Fragmentation in Inter-Network Protocols,"
Computer Networks, v. 3, n. 1, Febrero 1979.
[7] Strazisar, V., "How to Build a Gateway", IEN 109, Bolt Beranek and
Newman, Agosto 1979.
[8] Postel, J., "Service Mappings," RFC 795, USC/Information Sciences
[9] Postel, J., "Assigned Numbers," RFC 790, USC/Information Sciences
J. Postel
[Pg. 46]
Especificacin
Protocolo Internet, Versin 6 (IPv6)
Estatus de este Memorndum
Este documento especifica un protocolo del track de estndares
Internet para la comunidad Internet, y solicita debate y sugerencias
para mejoras. Por favor remtase a la edicin actual de los
"Estndares de Protocolos Oficiales Internet" (STD 1) para el estado
de estandarizacin y estatus de este protocolo. La distribucin de
este memorndum es ilimitada.
Aviso de Copyright
Copyright (C) La Sociedad Internet (1998). Todos los Derechos
Reservados.
Resumen
Este documento especifica la versin 6 del Protocolo Internet (IPv6),
algunas veces tambin referido como IP Siguiente Generacin o IPng.
Lista de Contenidos
1.
2.
3.
4.
Introduccin....................................................2
Terminologa....................................................3
Formato de la Cabecera IPv6.....................................4
Cabeceras de Extensin IPv6.....................................6
4.1 Orden de las Cabeceras de Extensin........................7
4.2 Opciones...................................................9
4.3 Cabecera Opciones de Salto a Salto........................11
4.4 Cabecera Enrutamiento.....................................12
4.5 Cabecera Fragmento........................................18
5.
6.
7.
8.
4.6 Cabecera Opciones de Destino..............................23

4.7 Cabecera No Hay Siguiente.................................24
Cuestiones de Tamao del Paquete...............................24
Etiquetas de Flujo.............................................25
Clases de Trfico..............................................26
Cuestiones de Protocolo de Capa Superior.......................27
8.1 Sumas de Verificacin de Capa Superior....................27
8.2 Tiempo de Vida Mximo de un Paquete.......................28
Deering & Hinden

RFC 2460
Track de Estndares
Especificacin del IPv6
[Pgina 1]
Diciembre 1998
8.3 Tamao Mximo de la Carga til de Capa Superior...........29

8.4 Contestando a Paquetes que Llevan Cabeceras Enrutamiento..29
Apndice A. Semntica y Uso del Campo Etiqueta de Flujo...........30
Apndice B. Pautas de Formateo para las Opciones..................32
Consideraciones de Seguridad......................................35
Reconocimientos...................................................35
Direcciones de los Autores........................................35
Direccin del Traductor al Castellano.............................35
Referencias.......................................................36
Cambios a partir de la RFC-1883...................................36
Declaracin de Copyright Completa.................................39
1. Introduccin
El IP versin 6 (IPv6) es la nueva versin del Protocolo Internet,
diseado como el sucesor para el IP versin 4 (IPv4) [RFC-791]. Los
cambios del IPv4 al IPv6 recaen principalmente en las siguientes
categoras:
o Capacidades de Direccionamiento Extendida
El IPv6 incrementa el tamao de direccin IP de 32 bits a
128 bits, para dar soporte a ms niveles de direccionamiento
jerrquico, un nmero mucho mayor de nodos direccionables,
y una autoconfiguracin ms simple de direcciones. La
escalabilidad del enrutamiento multienvo se mejora agregando
un campo "mbito" a las direcciones multienvo. Y se define
un nuevo tipo de direccin llamada "direccin envo a uno de",
usado para enviar un paquete a cualquiera de un grupo de nodos.
o Simplificacin del Formato de Cabecera
Algunos campos de la cabecera IPv4 se han sacado o se han hecho
opcional, para reducir el costo del caso comn de proceso de
tratamiento de paquete y para limitar el costo del ancho de
banda, de la cabecera IPv6.
o Soporte Mejorado para las Extensiones y Opciones
Los cambios en la manera en que se codifican las opciones de la

cabecera IP permiten un reenvo ms eficiente, lmites menos
rigurosos en la longitud de opciones, y mayor flexibilidad para
introducir nuevas opciones en el futuro.
o Capacidad de Etiquetado de Flujo
Una nueva capacidad se agrega para permitir el etiquetado de
paquetes que pertenecen a "flujos" de trfico particulares para
lo cul el remitente solicita tratamiento especial, como la
calidad de servicio no estndar o el servicio en "tiempo real".
Deering & Hinden
RFC 2460
Track de Estndares
[Pgina 2]
Diciembre 1998
o Capacidades de Autenticacin y Privacidad

Extensiones para utilizar autenticacin, integridad de los
datos, y (opcional) confidencialidad de los datos, se
especifican para el IPv6.
Este documento especifica la cabecera IPv6 bsica y las cabeceras de
extensin IPv6 y las opciones inicialmente definidas. Aborda tambin
cuestiones de tamao del paquete, las semnticas de las etiquetas de
flujo y las clases de trfico, y los efectos del IPv6 en protocolos
de capa superior. Los formatos y semnticas de las direcciones IPv6
son especificadas separadamente en [ADDRARCH]. La versin IPv6 del
ICMP, que a todas las implementaciones IPv6 se exige incluir, es
especificada en [ICMPv6].
2. Terminologa
nodo
- un dispositivo que implementa el IPv6.
enrutador
- un nodo que reenva paquetes IPv6 no explcitamente

destinados hacia s mismo. [Ver Nota abajo].
host
- cualquier nodo que no es un enrutador. [Ver Nota

abajo].
capa superior - una capa de protocolo inmediatamente encima del

IPv6. Ejemplos son los protocolos transporte tal
como el TCP y el UDP, protocolos control tal como
el ICMP, protocolos enrutamiento tal como el OSPF,
y protocolos internet o de capa inferior que estn
siendo "tunelizados" sobre (es decir, encapsulados
dentro) IPv6 tal como el IPX, el AppleTalk, o
el mismo IPv6.
enlace
- una facilidad de comunicacin o medio sobre el cual

los nodos pueden comunicarse en la capa de enlace,
es decir, la capa inmediatamente debajo del IPv6.
Ejemplos son las Ethernets (simples o de puentes);
enlaces PPP; X.25, Frame Relay, o redes ATM;

y "tneles" de capa internet (o superior), tal como
los tneles sobre IPv4 o sobre el mismo IPv6.
vecinos
- nodos conectados al mismo enlace.
interface
- lo que acopla un nodo a un enlace.
direccin
paquete
- un identificador de capa IPv6 para una interface o

un conjunto de interfaces.
- una cabecera IPv6 ms carga til.
Deering & Hinden

RFC 2460
Track de Estndares
[Pgina 3]
Diciembre 1998
MTU de enlace - la unidad de transmisin mxima, es decir, el

tamao del paquete mximo en octetos, que puede
transportarse sobre un enlace.
MTU de ruta
- la MTU de enlace mnima de todos los enlaces dentro
de una ruta entre un nodo origen y un nodo destino.
Nota: es posible, aunque inusual, para un dispositivo con interfaces
mltiples ser configurado para reenviar paquetes no autodestinados
que llegan desde algn conjunto (menos que todas) de sus interfaces,
y para descartar paquetes no autodestinados que llegan desde sus
otras interfaces. Un dispositivo semejante debe cumplir con los
requisitos de protocolo para enrutadores al recibir paquetes de, e
interactuar con vecinos sobre, las interfaces anteriores
(reenviantes). Debe cumplir con los requisitos de protocolo para
hosts la recibir paquetes de, e interactuar con vecinos sobre, las
interfaces posteriores (no reenviantes).
3. Formato de la Cabecera IPv6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Versin|Clase d Trfico|
Etiqueta de Flujo
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Longitud de la Carga til |Cabcera Siguien|Lmite d Saltos|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+
+
|
|
+
Direccin Origen
+
|
|
+
+
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+
+
|
|
+
Direccin Destino
+
|
|
+
+
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Versin
Nmero = 6 de versin del Protocolo

Internet de 4 bits.
Clase de Trfico
Campo clase de trfico de 8 bits. Ver la

seccin 7.
Etiqueta de Flujo
Etiqueta de flujo de 20 bits. Ver la

seccin 6.
Deering & Hinden

RFC 2460
Track de Estndares
[Pgina 4]
Diciembre 1998
Longitud de la Carga til Entero sin signo de 16 bits. Longitud de

la carga til IPv6, es decir, el resto del
paquete que sigue a esta cabecera IPv6, en
octetos. (Notar que cualesquiera de las
cabeceras de extensin [seccin 4]
presente es considerada parte de la carga
til, es decir, incluida en el conteo de
la longitud).
Cabecera Siguiente
Selector de 8 bits. Identifica el tipo de
cabecera que sigue inmediatamente a la
cabecera IPv6. Utiliza los mismos valores
que el campo Protocolo del IPv4 [RFC-1700
et seq.].
Lmite de Saltos
Entero sin signo de 8 bits. Decrementado

en 1 por cada nodo que reenva el paquete.
Se descarta el paquete si el Lmite de
Saltos es decrementado hasta cero.
Direccin Origen
Direccin de 128 bits del originador del

paquete. Ver la [ADDRARCH].
Direccin Destino
Direccin de 128 bits del recipiente
pretendido del paquete (posiblemente no el
ltimo recipiente, si est presente una
cabecera Enrutamiento). Ver la [ADDRARCH]
y la seccin 4.4.
Deering & Hinden

RFC 2460
Track de Estndares
[Pgina 5]
Diciembre 1998
4. Cabeceras de Extensin IPv6

En el IPv6, la informacin de capa internet opcional se codifica en
cabeceras separadas que se pueden colocar entre la cabecera IPv6 y
la cabecera de capa superior dentro de un paquete. Hay un nmero
pequeo de tales cabeceras de extensin, cada una identificada por
un valor de Cabecera Siguiente distinto. Segn lo ilustrado en estos
ejemplos, un paquete IPv6 puede llevar cero, una, o ms cabeceras de
extensin, cada una identificada por el campo Cabecera Siguiente de
la cabecera precedente:
+---------------+-----------------------| Cabecera IPv6 | Cabecera TCP + datos
|
|
|Cabcera Sig. = |
|
TCP
|
+---------------+-----------------------+---------------+----------------+-----------------------| Cabecera IPv6 |Cabcera Enrutam.| Cabecera TCP + datos
|
|
|
|Cabcera Sig. = |Cabecera Sig. = |
| Enrutamiento |
TCP
|
+---------------+----------------+-----------------------+---------------+----------------+-----------------+----------------| Cabecera IPv6 |Cabcera Enrutam.|Cabcera Fragmento|fragmento de Cab.
|
|
|
| TCP + datos
|Cabcera Sig. = |Cabecera Sig. = |Cabecera Sig. = |
| Enrutamiento | Fragmento |
TCP
|
+---------------+----------------+-----------------+----------------Con una excepcin, las cabeceras de extensin no son examinadas ni
procesadas por ningn nodo a lo largo de la ruta de entrega de un

paquete, hasta que el paquete alcance el nodo (o cada uno del
conjunto de nodos, en el caso de multienvo) identificado en el campo
Direccin Destino de la cabecera IPv6. All, el demultiplexaje normal
en el campo Cabecera Siguiente de la cabecera IPv6 invoca el mdulo
para procesar la primera cabecera de extensin, o la cabecera de capa
superior si no hay ninguna cabecera de extensin presente. El
contenido y la semntica de cada cabecera de extensin determinan si
se procede o no a la cabecera siguiente. Por lo tanto, las cabeceras
de extensin se deben procesar estrictamente en el orden que aparecen
en el paquete; un receptor no debe, por ejemplo, examinar a travs de
un paquete buscando un tipo en particular de cabecera de extensin y
procesar esa cabecera antes de procesar todas las precedentes.
Deering & Hinden

RFC 2460
Track de Estndares
[Pgina 6]
Diciembre 1998
La excepcin mencionada en el prrafo precedente es la cabecera

Opciones de Salto a Salto, la cual lleva informacin que debe ser
examinada y procesada por cada nodo a lo largo de la ruta de entrega
de un paquete, incluyendo los nodos de origen y de destino. La
cabecera Opciones de Salto a Salto, cuando est presente, debe seguir
inmediatamente a la cabecera IPv6. Su presencia es indicada por el
valor cero en el campo Cabecera Siguiente de la cabecera IPv6.
Si, como resultado de procesar una cabecera, un nodo necesita
proceder a la cabecera siguiente pero el valor Cabecera Siguiente en
la cabecera actual es desconocido por el nodo, debe descartar el
paquete y enviar un mensaje ICMP de Problema de Parmetro al origen
del paquete, con un valor Cdigo ICMP de 1 ("encontrado tipo de
Cabecera Siguiente desconocido") y el campo Puntero ICMP conteniendo
el desplazamiento del valor desconocido dentro del paquete original.
La misma accin se debera tomar si un nodo encuentra un valor
Cabecera Siguiente de cero en cualquier cabecera con excepcin de una
cabecera IPv6.
Cada cabecera de extensin es un entero mltiplo de 8 octetos de
largo, para conservar la alineacin de 8 octetos para las cabeceras
subsiguientes. Los campos Multiocteto dentro de cada cabecera de
extensin se alinean en sus lmites naturales, es decir, los campos
de ancho de n octetos son colocados en un entero mltiplo de n
octetos desde el inicio de la cabecera, para n = 1, 2, 4, o 8.
Una implementacin completa del IPv6 comprende la implementacin de
las siguientes cabeceras de extensin:
Opciones de Salto a Salto
Enrutamiento (Tipo 0)
Fragmento
Opciones de Destino
Autenticacin
Seguridad del Encapsulado de la Carga til

Las primeras cuatro estn especificadas en este documento; las
ltimas dos estn especificadas en la [RFC-2402] y la [RFC-2406],
respectivamente.
4.1 Orden de las Cabeceras de Extensin
Cuando ms de una cabecera de extensin se usa en un mismo paquete,
se recomienda que esas cabeceras aparezcan en el siguiente orden:
Cabecera
Cabecera
Cabecera
Cabecera
Cabecera
IPv6
Opciones de Salto a Salto
Opciones de Destino (nota 1)
Enrutamiento
Fragmento
Deering & Hinden

RFC 2460
Cabecera
Cabecera
Cabecera
Cabecera
Track de Estndares
[Pgina 7]
Diciembre 1998
Autenticacin (nota 2)
Seguridad del Encapsulado de la Carga til (nota 2)
Opciones de Destino (nota 3)
de Capa Superior
nota 1: para las opciones a ser procesadas por el primer

destino que aparece en el campo Direccin Destino
IPv6 ms los destinos subsiguientes listados en la
Cabecera Enrutamiento.
nota 2: recomendaciones adicionales con respecto al orden
relativo de las cabeceras Autenticacin y Seguridad
del Encapsulado de la Carga til se dan en la
[RFC-2406].
nota 3: para las opciones a ser procesadas solo por el
destino final del paquete.
Cada cabecera de extensin debe ocurrir solamente una vez, a
excepcin de la cabecera Opciones de Destino la cual debe de ocurrir
a lo sumo dos veces (una vez antes de una cabecera Enrutamiento y la
otra vez antes de una cabecera de capa superior).
Si la cabecera de capa superior es otra cabecera IPv6 (en el caso de
que el IPv6 sea tunelizado o encapsulado en el IPv6), puede ser
seguida por sus propias cabeceras de extensin, las cuales estn
separadamente sujetas a las mismas recomendaciones de orden.
Siempre y cuando se definan otras cabeceras de extensin, sus
restricciones de orden concerniente a las cabeceras arriba listadas
deben ser especificadas.
Los nodos IPv6 deben aceptar e intentar procesar cabeceras de
extensin en cualquier orden y cualquier nmero de veces que ocurran

en un mismo paquete, a excepcin de la cabecera Opciones de Salto a
Salto la cual est restringida a aparecer slo inmediatamente despus
de una cabecera IPv6. No obstante, se aconseja fuertemente que los
originadores de paquetes IPv6 se apeguen al orden recomendado arriba
hasta y a menos que especificaciones subsiguientes corrijan esa
recomendacin.
Deering & Hinden

RFC 2460
Track de Estndares
[Pgina 8]
Diciembre 1998
4.2 Opciones
Dos de las cabeceras de extensin actualmente definidas -- la
cabecera Opciones de Salto a Salto y la cabecera Opciones de Destino
-- llevan un nmero variable de "opciones" codificadas tipo-longitudvalor (TLV), de la siguiente forma:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - |Tipo de Opcin | Lon Datos Opc |Datos d la Opcin
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - Tipo de Opcin
Identificador de 8 bits del tipo de opcin.
Lon Datos Opc

Entero sin signo de 8 bits. Longitud del
campo Datos de la Opcin de esta opcin, en
octetos.
Datos de la Opcin Campo de longitud variable. Datos especficos
del Tipo de Opcin.
La secuencia de opciones dentro de una cabecera se deben procesar
estrictamente en el orden que aparecen en la cabecera; un receptor no
debe, por ejemplo, examinar a travs de una cabecera buscando un tipo
en particular de opcin y procesar esa opcin antes de procesar todas
las precedentes.
Los identificadores Tipo de Opcin se codifican internamente tales
que sus 2 bits de ms alto orden especifican la accin que se debe
tomar si el nodo IPv6 en proceso no reconoce el Tipo de Opcin:
00 - no tomar en cuenta esta opcin y continuar procesando la
cabecera.
01 - descartar el paquete.
10 - descartar el paquete y, sin tener en cuenta si o no la
Direccin Destino del paquete fue una direccin multienvo,
enviar un mensaje ICMP Problema de Parmetro, Cdigo 2, a la
Direccin Origen del paquete sealando el Tipo de Opcin
desconocido.
11 - descartar el paquete y, solo si la Direccin Destino del
paquete no fue una direccin multienvo, enviar un mensaje
ICMP Problema de Parmetro, Cdigo 2, a la Direccin Origen
del paquete sealando el Tipo de Opcin desconocido.
El tercer bit de ms alto orden del Tipo de Opcin especifica si o no
los Datos de la Opcin de esa opcin pueden modificar el enrutado
hacia el destino final del paquete. Cuando una cabecera Autenticacin
Deering & Hinden
RFC 2460
Track de Estndares
[Pgina 9]
Diciembre 1998
est presente en el paquete, para cualquier opcin cuyos datos pueden

modificar el enrutado, su campo entero Datos de la Opcin se debe
tratar como octetos de valor cero cuando se calcula o verifica el
valor de autenticidad del paquete.
0 - los Datos de la Opcin no modifican el enrutado.
1 - los Datos de la Opcin pueden modificar el enrutado.
Los tres bits de alto orden descritos arriba estn para ser tratados
como parte del Tipo de Opcin, no independientemente del Tipo de
Opcin. Es decir, una opcin en particular se identifica por un Tipo
de Opcin de 8 bits completo, no slo por los 5 bits de bajo orden
de un Tipo de Opcin.
El mismo espacio de enumeracin del Tipo de Opcin se usa tanto para
la cabecera Opciones de Salto a Salto como para la cabecera Opciones
de Destino. Sin embargo, la especificacin de una opcin en
particular puede restringir su uso a solamente una de esas dos
cabeceras.
Las opciones individuales pueden tener requisitos especficos de
alineacin, para asegurar que los valores multiocteto dentro de los
campos Datos de la Opcin caigan en lmites naturales. El requisito
de alineacin de una opcin se especifica usando la notacin xn+y, lo
que significa que el Tipo de Opcin debe aparecer en un entero
mltiplo de x octetos desde el inicio de la cabecera, ms y octetos.
Por ejemplo:
2n
significa cualquier desplazamiento de 2 octetos a partir del

comienzo de la cabecera.
8n+2 significa cualquier desplazamiento de 8 octetos a partir del

comienzo de la cabecera, ms 2 octetos.
Hay dos opciones de relleno las cuales se usan cuando es necesario
alinear opciones subsiguientes y rellenar la cabecera contenedora a
una longitud mltiplo de 8 octetos. Estas opciones de relleno deben
ser reconocidas por todas las implementaciones IPv6:
Opcin Pad1 (requisito de alineacin: ninguno)
+-+-+-+-+-+-+-+-+
|
0
|
+-+-+-+-+-+-+-+-+
NOTA! el formato de la opcin Pad1 es un caso especial -- no tiene
los campos longitud y valor.
La opcin Pad1 se usa para insertar un octeto de relleno dentro
del rea de Opciones de una cabecera. Si se requiere ms de un
Deering & Hinden
RFC 2460
Track de Estndares
[Pgina 10]
Diciembre 1998
octeto de relleno, la opcin PadN, descrita a continuacin, se

debera usar, en lugar de mltiples opciones Pad1.
Opcin PadN (requisito de alineacin: ninguno)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - |
1
| Lon Datos Opc |Datos d la Opcin
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - La opcin PadN se usa para insertar dos o ms octetos de relleno
dentro del rea de Opciones de una cabecera. Para N octetos de
relleno, el campo Lon Datos Opc contiene el valor N-2, y el campo
Datos de la Opcin consiste en N-2 octetos de valor cero.
El Apndice B contiene pautas de formateo para disear Opciones
nuevas.
4.3 Cabecera Opciones de Salto a Salto
La cabecera Opciones de Salto a Salto se usa para llevar informacin
opcional que debe ser examinada por cada nodo a lo largo de la ruta
de entrega de un paquete. La cabecera Opciones de Salto a Salto se
identifica por un valor Cabecera Siguiente de 0 en la cabecera IPv6,
y tiene el siguiente formato:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Cabcera Siguien| Lon Cab Ext |
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|
|
.
.
.
Opciones
.
.
.
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cabecera Siguiente Selector de 8 bits. Identifica el tipo de
cabecera que sigue inmediatamente a la cabecera
Opciones de Salto a Salto. Utiliza los mismos
valores que el campo Protocolo del IPv4 [RFC1700 et seq.].
Lon Cab Ext
Entero sin signo de 8 bits. Longitud de la

cabecera Opciones de Salto a Salto en unidades
de 8 octetos, no incluye los primeros 8 octetos.
Opciones
Campo de longitud variable, de longitud tal que

la cabecera Opciones de Salto a Salto completa
es un entero mltiplo de 8 octetos de largo.
Contiene una o ms opciones codificadas TLV,
como se describe en la seccin 4.2.
Deering & Hinden

RFC 2460
Track de Estndares
[Pgina 11]
Diciembre 1998
Las nicas opciones de salto a salto definidas en este documento son

las opciones Pad1 y PadN especificadas en la seccin 4.2.
4.4 Cabecera Enrutamiento
La cabecera Enrutamiento es utilizada por un origen IPv6 para listar
uno o ms nodos intermedio a ser "visitados" en el camino hacia el
destino de un paquete. Esta funcin es muy similar a las opciones
Origen Impreciso y Registro de Ruta del IPv4. La cabecera
Enrutamiento se identifica por una Cabecera Siguiente de valor 43 en
la cabecera inmediatamente precedente, y tiene el siguiente formato:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Cabcera Siguien| Lon Cab Ext |Tipo d Enrutami|Segmentos Dejad|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
.
.
.
datos especficos del tipo
.
.
.
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cabecera Siguiente
Selector de 8 bits. Identifica el tipo
de cabecera que sigue inmediatamente a
la cabecera Enrutamiento. Utiliza los
mismos valores que el campo Protocolo
del IPv4 [RFC-1700 et seq.].
Lon Cab Ext
Entero sin signo de 8 bits. Longitud de
la cabecera Enrutamiento en unidades de

8 octetos, no incluye los primeros 8
octetos.
Tipo de Enrutamiento
Identificador de 8 bits de una variante
en particular de cabecera Enrutamiento.
Segmentos Dejados
Entero sin signo de 8 bits. Nmero de
segmentos de ruta restantes, es decir,
nmero de nodos intermedio
explcitamente listados an a ser
visitados antes de alcanzar el destino
final.
Datos especficos del tipo Campo de longitud variable, de formato
determinado por el Tipo de Enrutamiento,
y de longitud tal que la cabecera
Enrutamiento completa es un entero
mltiplo de 8 octetos de largo.
Deering & Hinden

RFC 2460
Track de Estndares
[Pgina 12]
Diciembre 1998
Si, al procesar un paquete recibido, un nodo encuentra una cabecera

Enrutamiento con un valor Tipo de Enrutamiento desconocido, el
comportamiento requerido del nodo depende del valor del campo
Segmentos Dejados, como sigue:
Si Segmentos Dejados es cero, el nodo debe ignorar la cabecera
Enrutamiento y proceder a procesar la siguiente cabecera en el
paquete, cuyo tipo se identifica por el campo Cabecera Siguiente
en la cabecera Enrutamiento.
Si Segmentos Dejados no es cero, el nodo debe descartar el paquete
y enviar un mensaje ICMP Problema de Parmetro, Cdigo 0, a la
Direccin Origen del paquete, apuntando al Tipo de Enrutamiento
desconocido.
Si, despus de procesar una cabecera Enrutamiento de un paquete
recibido, un nodo intermedio determina que el paquete ser remitido
hacia un enlace cuya MTU de enlace es menor que el tamao del
paquete, el nodo debe descartar el paquete y enviar un mensaje ICMP
Paquete Demasiado Grande a la Direccin Origen del paquete.
Deering & Hinden

RFC 2460
Track de Estndares
[Pgina 13]
Diciembre 1998
La cabecera Enrutamiento de Tipo 0 tiene el siguiente formato:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Cabcera Siguien| Lon Cab Ext |Tipo Enrutami=0|Segmentos Dejad|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Reservado
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+
+
|
|
+
Direccin[1]
+
|
|
+
+
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+
+
|
|
+
Direccin[2]
+
|
|
+
+
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.
.
.
.
.
.
.
.
.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+
+
|
|
+
Direccin[n]
+
|
|
+
+
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cabecera Siguiente
cabecera Enrutamiento. Utiliza los mismos
valores que el campo Protocolo del IPv4 [RFC1700 et seq.].
Lon Cab Ext

cabecera Enrutamiento en unidades de 8
octetos, sin incluir los primeros 8 octetos.
Para la cabecera Enrutamiento de Tipo 0, Lon
Cab Ext es igual a dos veces el nmero de
direcciones en la cabecera.
Tipo de Enrutamiento 0.
Deering & Hinden
RFC 2460
Track de Estndares
[Pgina 14]
Diciembre 1998
Segmentos Dejados
Entero sin signo de 8 bits. Nmero de
segmentos de ruta restantes, es decir, nmero
de nodos intermedio explcitamente listados
an a ser visitados antes de alcanzar el
destino final.
Reservado
Campo reservado de 32 bits. Inicializado a

cero para la transmisin; ignorado en la
recepcin.
Direccin[1..n]
Vector de direcciones de 128 bits, numerados
desde 1 hasta n.
Las direcciones multienvo no deben aparecer en una cabecera
Enrutamiento de Tipo 0, o en el campo Direccin Destino IPv6 de un
paquete que lleva una cabecera Enrutamiento de Tipo 0.
Una cabecera Enrutamiento no se examina o procesa hasta que alcance
el nodo identificado en el campo Direccin Destino de la cabecera
IPv6. En ese nodo, al despachar el campo Cabecera Siguiente de la
cabecera inmediatamente precedente ocasiona que el mdulo cabecera
Enrutamiento sea invocado, el cual, en el caso de Enrutamiento Tipo
0, lleva a cabo el siguiente algoritmo:
Deering & Hinden

RFC 2460
Track de Estndares
[Pgina 15]
Diciembre 1998
si Segmentos Dejados = 0 {
proceder a procesar la cabecera siguiente en el paquete, cuyo tipo
se identifica por el campo Cabecera Siguiente en la cabecera
Enrutamiento
}
sino si Lon Cab Ext es impar {
Direccin Origen, apuntando al campo Lon Cab Ext, y descartar
el paquete
}
sino {
calcular n, el nmero de direcciones en la cabecera Enrutamiento,
al dividir Lon Cab Ext por 2
si Segmentos Dejados es mayor que n {
Direccin de Origen, apuntando al campo Segmentos Dejados, y
descartar el paquete
}
sino {
decrementar Segmentos Dejados en 1;
calcular i, el ndice de la direccin siguiente a ser visitado
en el vector de direccin, substrayendo Segmentos Dejados de n
si la Direccin [i] o la Direccin Destino IPv6 es multienvo {
}
sino {
intercambiar la Direccin Destino IPv6 y la Direccin [i]
si el Lmite de Saltos es menor que o iguala a 1 {
enviar un mensaje ICMP Tiempo Excedido -- Lmite de
Saltos Excedido en Transito a la Direccin Origen y
}
sino {
decrementar el Lmite de Saltos en 1
}
}
resometer el paquete al mdulo IPv6 para la transmisin

hacia el nuevo destino
Deering & Hinden

RFC 2460
Track de Estndares
[Pgina 16]
Diciembre 1998
Como un ejemplo de los efectos del algoritmo de arriba, considerar el

caso de un nodo origen S que enva un paquete al nodo de destino D,
usando una cabecera Enrutamiento para causar que el paquete sea
enrutado va los nodos intermedio I1, I2, e I3. Los valores de los
campos pertinentes de la cabecera IPv6 y de la cabecera Enrutamiento
en cada segmento de la ruta de entrega seran como sigue:
Conforme el paquete viaja de S a I1:
Direccin de Origen = S
Lon Cab Ext = 6
Direccin de Destino = I1
Segmentos Dejados = 3
Direccin[1] = I2
Direccin[2] = I3
Direccin[3] = D
Conforme el paquete viaja de I1 a I2:
Lon Cab Ext = 6
Direccin[1] = I1
Direccin[2] = I3
Direccin[3] = D
Conforme el paquete viaja de I2 a I3:
Lon Cab Ext = 6
Direccin[1] = I1
Direccin[2] = I2
Direccin[3] = D
Conforme el paquete viaja de I3 a D:
Lon Cab Ext = 6
Direccin de Destino = D
Direccin[1] = I1
Direccin[2] = I2
Direccin[3] = I3
Deering & Hinden

RFC 2460
Track de Estndares
[Pgina 17]
Diciembre 1998
4.5 Cabecera Fragmento

La cabecera Fragmento es utilizada por un origen IPv6 para enviar un
paquete ms grande de lo que cabra en la MTU de la ruta hacia su
destino. (Nota: a diferencia del IPv4, la fragmentacin en el IPv6
slo se lleva a cabo por los nodos origen, no por los enrutadores a
lo largo de la ruta de entrega de un paquete -- ver seccin 5.) La
cabecera Fragmento se identifica por un valor Cabecera Siguiente de
44 en la cabecera inmediatamente precedente, y tiene el siguiente
formato:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Cabcera Siguien| Reservado |Dsplazamiento dl Fragment|Res|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Identificacin
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cabecera Siguiente
Selector de 8 bits. Identifica el tipo

de cabecera inicial de la Parte
Fragmentable del paquete original
(definido abajo). Usa los mismos
valores que el campo Protocolo del
IPv4 [EL RFC-1700 ET SEQ.].
Reservado
Campo reservado de 8 bits.

Inicializado a cero para la
transmisin; ignorado en la recepcin.
Desplazamiento del Fragmento Entero sin signo de 13 bits. El

desplazamiento, en unidades de 8
octetos, de los datos que siguen a
esta cabecera, relativo al comienzo de
la Parte Fragmentable del paquete
original.
Res
Campo reservado de 2 bits.

Inicializado a cero para la
transmisin; ignorado en la recepcin.
Bandera M
1 = ms fragmentos;
0 = ltimo fragmento.
Identificacin
32 bits. Ver descripcin abajo.
Para enviar un paquete que es demasiado grande para caber en la MTU

de la ruta hacia su destino, un nodo origen puede dividir el paquete
en fragmentos y enviar cada fragmento como un paquete separado, para
ser reensamblado en el receptor.
Deering & Hinden

RFC 2460
Track de Estndares
[Pgina 18]
Diciembre 1998
Por cada paquete que ser fragmentado, el nodo origen genera un valor
Identificacin. La Identificacin debe ser diferente que el de
cualquier otro paquete fragmentado enviado recientemente* con la
misma Direccin Origen y Direccin Destino. Si una cabecera
Enrutamiento est presente, la Direccin Destino de inters es la del
destino final.
* "recientemente" significa dentro del mximo tiempo de vida
probable de un paquete, incluyendo el tiempo de trnsito del
origen hacia el destino y el tiempo gastado esperando el
reensemblaje con otros fragmentos del mismo paquete. Sin
embargo, no se requiere que un nodo origen conozca el mximo
tiempo de vida de un paquete. Ms bien, se asume que el
requisito puede encontrarse manteniendo el valor Identificacin
como un simple, contador "envoltura alrededor", de 32 bits,
incrementado cada vez que un paquete debe fragmentarse. Es una
opcin de implementacin si para mantener a un solo contador
para el nodo o contadores mltiples, por ejemplo, uno para cada
una de las posibles direcciones origen del nodo, o uno para cada
combinacin (direccin origen, direccin destino) activa.
El paquete inicial, grande, no fragmentado es referido como el
"paquete original", y se considera que consiste en dos partes, tal

como se ilustra:
paquete original:
+------------------+----------------------//-----------------------+
|
Parte
|
Parte
|
| No Fragmentable |
Fragmentable
+------------------+----------------------//-----------------------+
La Parte No Fragmentable consiste en la cabecera IPv6 ms

cualesquiera de las cabeceras de extensin que debe procesarse por
nodos en camino hacia el destino, es decir, todas las cabeceras e
incluso la cabecera Enrutamiento si esta presente, sino la
cabecera Opciones de Salto a Salto si esta presente, sino ninguna
de las cabeceras de extensin.
La Parte Fragmentable consiste en el resto del paquete, es decir,
cualquiera de las cabeceras de extensin que necesita que slo se
procese por el nodo(s) destino final, ms la cabecera de capa
superior y los datos.
La Parte Fragmentable del paquete original es dividida en fragmentos,
cada uno, excepto posiblemente el ltimo ("el de la extrema
derecha"), siendo un entero mltiplo de 8 octetos de largo. Los
fragmentos se transmiten en "paquetes fragmento" separados tal como
se ilustra:
Deering & Hinden
RFC 2460
Track de Estndares
[Pgina 19]
Diciembre 1998
paquete original:
+------------------+--------------+--------------+--//--+----------+
|
Parte
| primer | segundo |
| ltimo |
| No Fragmentable | fragmento | fragmento | .... | fragmento|
+------------------+--------------+--------------+--//--+----------+
paquetes fragmento:
+------------------+--------+--------------+
|
Parte
|Cabecera| primer |
| No Fragmentable |Fragment| fragmento |
+------------------+--------+--------------+
+------------------+--------+--------------+
|
Parte
|Cabecera| segundo |
| No Fragmentable |Fragment| fragmento |
+------------------+--------+--------------+
o
o
o
+------------------+--------+----------+
|
Parte
|Cabecera| ltimo |
| No Fragmentable |Fragment| fragmento|
+------------------+--------+----------+
Cada paquete fragmento est compuesto de:
(1) La Parte No Fragmentable del paquete original, con la Longitud
de la Carga til de la cabecera IPv6 original cambiada para
contener la longitud de tan slo este paquete fragmento
(excluyendo la longitud de la propia cabecera IPv6), y el
campo Cabecera Siguiente de la ltima cabecera de la Parte No
Fragmentable cambiado a 44.
(2) Una cabecera Fragmento conteniendo:
El valor Siguiente Cabecera que identifica la primera
cabecera de la Parte Fragmentable del paquete original.
Un Desplazamiento del Fragmento que contiene el
desplazamiento del fragmento, en unidades de 8 octetos,
relativo al comienzo de la Parte Fragmentable del paquete
original. El Desplazamiento del Fragmento del primer ("el
de la extrema izquierda") fragmento es 0.
Una bandera M de valor 0 si el fragmento es el ltimo
("el de la extrema derecha"), sino una bandera M de valor
1.
Deering & Hinden
RFC 2460
Track de Estndares
[Pgina 20]
Diciembre 1998
El valor Identificacin generado para el paquete

original.
(3) El propio fragmento.
Deben escogerse las longitudes de los fragmentos tal que los paquetes
fragmento resultantes quepan dentro de la MTU de la ruta hacia el(los)
destino(s) del paquete.
En el destino, se reensamblan los paquetes fragmento en su forma
original, no fragmentada, tal como se ilustra:
paquete original reensamblado:
+------------------+----------------------//-----------------------+
|
Parte
|
Parte
|
| No Fragmentable |
Fragmentable
+------------------+----------------------//-----------------------+
Las siguientes reglas gobiernan el reensamblaje:
Un paquete original slo se reensambla a partir de paquetes

fragmento que tienen la misma Direccin Origen, Direccin Destino,
e Identificacin del Fragmento.
La Parte No Fragmentable del paquete reensamblado consiste en
todas las cabeceras, pero sin incluir, la cabecera Fragmento del
primer paquete fragmento (es decir, el paquete cuyo Desplazamiento
del Fragmento es cero), con los siguiente dos cambios:
El campo Cabecera Siguiente de la ltima cabecera de la Parte
No Fragmentable se obtiene del campo Cabecera Siguiente de la
cabecera Fragmento del primer fragmento.
Se calcula la Longitud de la Carga til del paquete
reensamblado a partir de la longitud de la Parte No
Fragmentable y de la longitud y desplazamiento del ltimo
fragmento. Por ejemplo, una frmula para calcular la Longitud
de la Carga til del paquete original reensamblado es:
LCU.orig = LCU.inicial - LF.inicial - 8 + (8*DF.final) +
LF.final
donde
LCU.orig
= campo Longitud de la Carga til del paquete

reensamblado.
LCU.inicial = campo Longitud de la Carga til del primer
paquete fragmento.
LF.inicial = longitud del fragmento siguiente a la cabecera
Fragmento del primer paquete fragmento.
Deering & Hinden
RFC 2460
DF.final
LF.final
Track de Estndares
[Pgina 21]
Diciembre 1998
= campo Desplazamiento del Fragmento de la

cabecera Fragmento del ltimo paquete
fragmento.
= longitud del fragmento siguiente a la cabecera
Fragmento del ltimo paquete fragmento.
La Parte Fragmentable del paquete reensamblado se construye a

partir de los fragmentos siguientes a las cabeceras Fragmento
dentro de cada uno de los paquetes fragmento. La longitud de cada
fragmento es calculada substrayendo de la Longitud de la Carga
til del paquete la longitud de las cabeceras entre la cabecera
IPv6 y el propio fragmento, su posicin relativa en la Parte
Fragmentable se calcula a partir de su valor Desplazamiento del
Fragmento.
La cabecera Fragmento no est presente en el paquete reensamblado,
final.
Las siguientes condiciones de error pueden originarse al reensamblar
paquetes fragmentados:
Si se reciben fragmentos insuficientes para completar el
reensamblaje de un paquete dentro de los 60 segundos a partir de
la recepcin del primer fragmento en llegar de ese paquete, el
reensamblaje de ese paquete debe abandonarse y deben descartarse
todos los fragmentos que se han recibido para ese paquete. Si el
primer fragmento (es decir, el nico con un Desplazamiento del
Fragmento de cero) se ha recibido, un mensaje ICMP Tiempo Excedido
-- Tiempo Excedido para el Reensamblaje del Fragmento, debe
enviarse al origen de ese fragmento.
Si la longitud de un fragmento, tal como se dedujo a partir del
campo Longitud de la Carga til del paquete fragmento, no es un
mltiplo de 8 octetos y la bandera M de ese fragmento es 1,
entonces ese fragmento debe descartarse y un mensaje ICMP Problema
de Parmetro, Cdigo 0, debe enviarse al origen del fragmento,
apuntando al campo Longitud de la Carga til del paquete
fragmento.
Si la longitud y el desplazamiento de un fragmento son tales que
la Longitud de la Carga til del paquete reensamblado de ese
fragmento excedera los 65,535 octetos, entonces ese fragmento
debe descartarse y un mensaje ICMP Problema de Parmetro, Cdigo
0, debe enviarse al origen del fragmento, apuntando al campo
Desplazamiento del Fragmento del paquete fragmento.
No se espera que las siguientes condiciones ocurran, pero no se
consideran errores si lo hacen:
Deering & Hinden

RFC 2460
Track de Estndares
[Pgina 22]
Diciembre 1998
El nmero y contenido de las cabeceras que preceden a la cabecera

Fragmento de fragmentos diferentes del mismo paquete original
pueden diferir. Cualesquiera de las cabeceras que estn presentes,
precediendo a la cabecera Fragmento en cada paquete fragmento, se
procesan cuando los paquetes llegan, previamente a que los
fragmentos hagan cola para el reensamblaje. Slo aquellas
cabeceras en el paquete fragmento de Desplazamiento cero se
retienen en el paquete reensamblado.
Los valores Cabecera Siguiente en las cabeceras Fragmento de
fragmentos diferentes del mismo paquete original pueden diferir.
Slo el valor del paquete fragmento de Desplazamiento cero se usa
para el reensamblaje.
4.6 Cabecera Opciones de Destino
La cabecera Opciones de Destino es usada para llevar informacin
opcional que necesita ser examinada solamente por el(los) nodo(s)
destino del paquete. La cabecera Opciones de Destino es identificada

por un valor Cabecera Siguiente de 60 en la cabecera inmediatamente
precedente, y tiene el siguiente formato:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Cabcera Siguien| Lon Cab Ext |
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|
|
.
.
.
Opciones
.
.
.
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cabecera Siguiente
cabecera Opciones de Destino. Utiliza los
mismos valores que el campo Protocolo del
IPv4 [RFC-1700 et seq.].
Lon Cab Ext

cabecera Opciones de Destino en unidades de 8
octetos, no incluye los primeros 8 octetos.
Opciones
Campo de longitud variable, de longitud tal

que la cabecera Opciones de Destino completa
es un entero mltiplo de 8 octetos de largo.
Contiene uno o ms opciones codificadas TLV,
tal como se describe en la seccin 4.2.
Las nicas opciones de destino definidas en este documento son las

opciones Pad1 y PadN especificadas en la seccin 4.2.
Deering & Hinden
RFC 2460
Track de Estndares
[Pgina 23]
Diciembre 1998
Notar que hay dos posibles maneras de codificar informacin de

destino opcional en un paquete IPv6: como una opcin en la cabecera
Opciones de Destino, o como una cabecera de extensin separada. La
cabecera Fragmento y la cabecera Autenticacin son ejemplos de la ms
reciente propuesta. Qu propuesta puede ser usada depende de qu
accin es deseada de un nodo destino que no entiende la informacin
opcional:
o Si la accin deseada es que el nodo destino descarte el paquete
y, slo si la Direccin Destino del paquete no es una direccin
multienvo, enviar un mensaje ICMP Tipo No reconocido a la
Direccin Origen del paquete, luego la informacin puede ser
codificada como una cabecera separada o como una opcin en la
cabecera Opciones de Destino cuyo Tipo de Opcin tiene el valor
11 en sus dos bits de ms alto orden. La eleccin puede
depender de factores tales como cual toma menos octetos, o cual
rinde mejor alineacin o ms eficiente anlisis.
o Si alguna otra accin es deseada, la informacin debe ser

codificada como una opcin en la cabecera Opciones de Destino
cuyo Tipo de Opcin tiene el valor 00, 01, o 10 en sus dos bits
de ms alto orden, especificando la accin deseada (ver seccin
4.2).
4.7 Cabecera No Hay Siguiente
El valor 59 en el campo Cabecera Siguiente de una cabecera IPv6 o de
cualquier cabecera de extensin indica que nada hay siguiendo esa
cabecera. Si el campo Longitud de la Carga til de la cabecera IPv6
indica la presencia de octetos ms all del final de una cabecera
cuyo campo Cabecera Siguiente contiene 59, esos octetos deben
ignorarse, y pasarse inalterados si el paquete se reenva.
5. Cuestiones de Tamao del Paquete
El IPv6 requiere que cada enlace en la internet tenga una MTU de 1280
octetos o mayor. En cualquier enlace que no pueda llevarse un paquete
de 1280 octetos en una pieza, debe proporcionarse fragmentacin y
reensamblaje especifico al enlace en una capa debajo del IPv6.
Los Enlaces que tienen una MTU configurable (por ejemplo, enlaces PPP
[RFC-1661]) deben configurarse para tener una MTU de por lo menos
1280 octetos; se recomienda que sean configurados con una MTU de 1500
octetos o mayor, para alojar posibles encapsulaciones (es decir,
tunelizar) sin incurrir en la fragmentacin de la capa IPv6.
De cada enlace al cul un nodo se conecta directamente, el nodo debe
poder aceptar paquetes tan grandes como la MTU de ese enlace.
Deering & Hinden

RFC 2460
Track de Estndares
[Pgina 24]
Diciembre 1998
Se recomienda fuertemente que los nodos IPv6 implementen el

Descubrimiento de la MTU de la Ruta [RFC-1981] con el propsito de
descubrir y tomar ventaja de las rutas con MTUs mayores que 1280
octetos. Sin embargo, una implementacin IPv6 mnima (por ejemplo, en
una ROM de inicio) puede restringirse simplemente a enviar paquetes
no ms grandes que 1280 octetos, y omitir la implementacin del
Descubrimiento de la MTU de la Ruta.
Con el propsito de enviar un paquete ms grande que la MTU de la
ruta, un nodo puede utilizar la cabecera Fragmento IPv6 para
fragmentar el paquete en el origen y tenerlo reensamblado en el(los)
destino(s). Sin embargo, el uso de tal fragmentacin se desalienta en
cualquier aplicacin que pueda ajustar sus paquetes para satisfacer
la MTU de la ruta medida (es decir, por debajo de los 1280 octetos).
Un nodo debe poder aceptar un paquete fragmentado que, despus del
reensamblaje, sea tan grande como de 1500 octetos. Se permite a un

nodo aceptar paquetes fragmentados de tal manera que reensamblan a
ms de 1500 octetos. Un protocolo o aplicacin de capa superior que
depende de la fragmentacin IPv6 para enviar paquetes ms grandes
que la MTU de una ruta no debe enviar paquetes ms grandes que 1500
octetos a menos que tenga la certidumbre que el destino es capaz
reensamblar paquetes de esos tamaos tan grandes.
En contestacin a un paquete IPv6 que se enva a un destino IPv4 (es
decir, un paquete que experimenta la traduccin del IPv6 al IPv4), el
nodo IPv6 originante puede recibir un mensaje ICMP Paquete Demasiado
Grande reportando de una MTU del Salto Siguiente menor a 1280. En ese
caso, no se exige que el nodo IPv6 reduzca el tamao de los paquetes
subsiguientes a menos de 1280, pero debe incluir una cabecera
Fragmento en esos paquetes para que el enrutador traductor de IPv6 a
IPv4 pueda obtener un valor Identificacin apropiado para usar en los
fragmentos IPv4resultantes. Note que esto significa que la carga til
puede tener que ser reducida a 1232 octetos (1280 menos 40 para la
cabecera IPv6 y 8 para la cabecera Fragmento), y ms pequea todava
si se usan cabeceras de extensin adicionales.
6. Etiquetas de Flujo
El campo Etiqueta de Flujo de 20 bits en la cabecera IPv6 puede ser
usado por un origen para etiquetar secuencias de paquetes para los
cuales solicita un manejo especial por los enrutadores IPv6, tal como
la calidad de servicio no estndar o el servicio en "tiempo real".
Este aspecto del IPv6 est, al momento de escribir, todava
experimental y sujeto a cambio conforme los requisitos para dar
soporte a flujos en la Internet se vuelvan ms claros. Se exige a los
hosts o a los enrutadores que no dan soporte a las funciones del
campo Etiqueta de Flujo poner el campo a cero al originar un paquete,
pasar el campo inalterado al reenviar un paquete, e ignorar el campo
al recibir un paquete.
Deering & Hinden
RFC 2460
Track de Estndares
[Pgina 25]
Diciembre 1998
El Apndice A describe la semntica y uso del campo etiqueta de flujo

pretendido en vigencia.
7. Clases de Trfico
El campo de 8 bits Clase de Trfico en la cabecera IPv6 est
disponible para usarse por nodos originantes y/o enrutadores
reenviantes para identificar y distinguir entre las diferentes clases
o prioridades de paquetes IPv6. En el momento en que esta
especificacin est siendo escrita, hay un cierto numero de
experimentos en camino en cuanto al uso de los bits Tipo de Servicio
IPv4 y/o Anterioridad para proporcionar varias formas de "servicio
diferenciado" para paquetes IP, adems de a travs del uso de un
flujo establecido explcito. El campo Clase de Trfico en la cabecera
IPv6 esta proyectado para permitir similar funcionalidad que ser
soportada en el IPv6.
Se espera que esos experimentos conduzcan eventualmente hacia un
acuerdo en que orden las clasificaciones de trfico son mas tiles
para los paquetes IP. Las definiciones detalladas de la sintaxis y
semntica de todos o algunos de los bits Clase de Trfico IPv6, si es
experimental o proyectado para eventual estandarizacin, sern
proporcionados en documentos separados.
Los siguientes requisitos generales se aplican al campo Clase de
Trfico:
o La interface de servicio para el servicio IPv6 dentro de un
nodo debe proporcionar un medio para que un protocolo de capa
superior proporcione el valor de los bits Clase de Trfico en
los paquetes originados por ese protocolo de capa superior. El
valor por defecto debe ser cero para todos los 8 bits.
o Los nodos que soportan un uso (experimental o estndar
eventual) especifico de algunos o todos los bits Clase de
Trfico se les permite cambiar el valor de esos bits en los
paquetes que ellos originan, reenvan, o reciben, como sea
requerido para ese uso especfico. Los nodos deben ignorar y
dejar sin alterar a cualesquiera de los bits del campo Clase de
Trfico para los cuales no dan soporte a un uso especfico.
o Un protocolo de capa superior no debe asumir que el valor de
los bits Clase de Trfico en un paquete recibido son los mimos
que el valor enviado por el origen del paquete.
Deering & Hinden

RFC 2460
Track de Estndares
[Pgina 26]
Diciembre 1998
8. Problemas de Protocolo de Capa Superior

8.1 Sumas de Verificacin de Capa Superior
Cualquier protocolo de transporte u otro de capa superior que incluya
las direcciones de la cabecera IP en su clculo de suma de
verificacin debe modificarse para el uso sobre el IPv6, para incluir
las direcciones IPv6 de 128 bits en lugar de las direcciones IPv4 de
32 bits. En particular, la siguiente ilustracin muestra la "pseudo
cabecera" TCP y UDP para el IPv6:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+
+
|
|
+
Direccin Origen
+
|
|
+
+
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+
+
|
|
+
Direccin Destino
+
|
|
+
+
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Longitud del Paquete de Capa Superior
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
cero
|Cabcera Siguien|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Si el paquete IPv6 contiene una cabecera Enrutamiento, la
Direccin Destino usada en la pseudo cabecera es la del destino
final. En el nodo originante, esa direccin estar en el ltimo
elemento de la cabecera Enrutamiento; en el(los) receptor(res),
esa direccin estar en el campo Direccin Destino de la
cabecera IPv6.
o El valor Cabecera Siguiente en la pseudo cabecera identifica el
protocolo de capa superior (por ejemplo, 6 para el TCP, o 17
para el UDP). Diferir del valor Cabecera Siguiente en la
cabecera IPv6 si hay cabeceras de extensin entre la cabecera
IPv6 y la cabecera de capa superior.
o La Longitud del Paquete de Capa Superior en la pseudo cabecera
es la longitud de la cabecera de capa superior y los datos (por
ejemplo, la cabecera TCP ms los datos TCP). Algunos protocolos
Deering & Hinden
RFC 2460
Track de Estndares
[Pgina 27]
Diciembre 1998
de capa superior llevan su propia informacin de longitud (por

ejemplo, el campo Longitud en la cabecera UDP); para tales
protocolos, esa es la longitud usada en la pseudo cabecera.
Otros protocolos (como el TCP) no llevan su propia informacin
de longitud, en cuyo caso la longitud usada en la pseudo
cabecera es la Longitud de la Carga til de la cabecera IPv6,
menos la longitud de cualquier cabecera de extensin presente
entre la cabecera IPv6 y la cabecera de capa superior.
o A diferencia del IPv4, cuando los paquetes UDP son originados
por un nodo IPv6, la suma de verificacin UDP no es opcional.
Es decir, siempre que se origine un paquete UDP, un nodo IPv6
debe calcular una suma de verificacin UDP sobre el paquete y
la pseudo cabecera, y, si ese clculo produce un resultado de

cero, debe cambiarse al hexadecimal FFFF para la colocacin en
la cabecera UDP. Los receptores IPv6 deben descartar los
paquetes UDP que contengan una suma de verificacin cero, y
deben registrar el error.
La versin IPv6 del ICPM [ICMPv6] incluye la pseudo cabecera citada
arriba en su clculo de suma de verificacin; ste es un cambio a
diferencia de la versin IPv4 del ICMP, el cual no incluye una pseudo
cabecera en su suma de verificacin. La razn para el cambio es para
proteger al ICMP de una mala entrega o corrupcin de aquellos campos
de la cabecera IPv6 de los que depende, los qu, a diferencia del
IPv4, no son cubiertos por una suma de verificacin de la capa
internet. El campo Cabecera Siguiente en la pseudo cabecera para el
ICMP contiene el valor 58, que identifica la versin IPv6 del ICMP.
8.2 Tiempo de Vida Mximo de un Paquete
A diferencia del IPv4, no se exigen a los nodos IPv6 cumplir con el
tiempo de vida mximo de un paquete. sa es la razn por la que el
campo "Tiempo de Vida" del IPv4 se renombr a "Lmite de Saltos" en
el IPv6. En la prctica, muy pocas, si alguna, implementaciones IPv4
adoptan el requisito de limitar el tiempo de vida de un paquete, asi
que esto no es un cambio en la prctica. Cualquier protocolo de capa
superior que depende de la capa internet (ya sea IPv4 o IPv6) para
limitar el tiempo de vida de un paquete debe actualizarse para
proporcionar sus propios mecanismos de deteccin y descarte de
paquetes obsoletos.
Deering & Hinden

RFC 2460
Track de Estndares
[Pgina 28]
Diciembre 1998
8.3 Tamao Mximo de la Carga til de Capa Superior

Al calcular el tamao mximo de carga til disponible para los datos
de capa superior, un protocolo de capa superior debe tener en cuenta
el tamao ms grande de la cabecera IPv6relativo a la cabecera IPv4.
Por ejemplo, en el IPv4, la opcin MSS del TCP se calcula como el
tamao mximo de paquete (un valor por defecto o un valor aprendido a
travs del Descubrimiento de la MTU de la Ruta) menos 40 octetos (20
octetos para la longitud mnima de la cabecera IPv4 y 20 octetos para
la longitud mnima de la cabecera TCP). Al usar TCP sobre IPv6, el
MSS debe calcularse como el tamao mximo de paquete menos 60
octetos, puesto que la longitud mnima de la cabecera IPv6 (es decir,
una cabecera IPv6 sin cabeceras de extensin) es 20 octetos ms larga

que la longitud mnima de la cabecera IPv4.
8.4 Contestando a Paquetes que Llevan Cabeceras Enrutamiento
Cuando un protocolo de capa superior enva uno o ms paquetes en
contestacin a un paquete recibido que inclua una cabecera
Enrutamiento, el(los) paquete(s) respuesta no debe(n) incluir una
cabecera Enrutamiento que se deriv automticamente "invirtiendo" la
cabecera Enrutamiento recibida A MENOS QUE se hayan verificado la
integridad y autenticidad tanto de la Direccin Origen como de la
cabecera Enrutamiento recibida (por ejemplo, mediante el uso de una
cabecera Autenticacin en el paquete recibido). En otras palabras, se
permiten slo los siguientes tipos de paquetes en contestacin a un
paquete recibido que lleva una cabecera Enrutamiento:
o Los paquetes respuesta que no llevan cabeceras Enrutamiento.
o Los paquetes respuesta que llevan cabeceras Enrutamiento que NO
se derivaron invirtiendo la cabecera Enrutamiento del paquete
recibido (por ejemplo, una cabecera Enrutamiento proporcionada
por configuracin local).
o Los paquetes respuesta que llevan cabeceras Enrutamiento que se
derivaron invirtiendo la cabecera Enrutamiento del paquete
recibido SI Y SLO SI la integridad y autenticidad de la
Direccin Origen y de la cabecera Enrutamiento del paquete
recibido han sido verificadas por el contestador.
Deering & Hinden

RFC 2460
Track de Estndares
[Pgina 29]
Diciembre 1998
Apndice A. Uso y Semntica del Campo Etiqueta de Flujo

Un flujo es una secuencia de paquetes enviada desde un origen
determinado hacia un destino (unienvo o multienvo) determinado para
el cual el origen desea un tratamiento especial por los enrutadores
intermedios. Podra transmitirse la naturaleza de ese tratamiento
especial hacia los enrutadores por un protocolo control, tal como el
protocolo reservacin de recurso, o por informacin dentro de los
mismos paquetes del flujo, por ejemplo, en una opcin de salto a
salto. Los detalles de tales protocolos control u opciones estn
fuera del mbito de este documento.
Pueden haber flujos activos mltiples desde un origen hacia un

destino, as como tambin trfico que no esta asociado con algn
flujo. Un flujo se identifica singularmente por la combinacin de una
direccin origen y una etiqueta de flujo no cero. Los paquetes que no
pertenecen a un flujo llevan una etiqueta de flujo de cero.
Una etiqueta de flujo se asigna a un flujo en el nodo origen del
flujo. Deben escogerse nuevas etiquetas de flujo (pseudo)
aleatoriamente y uniformemente del rango 1 al FFFFF en hexadecimal.
El propsito de la asignacin al azar es para hacer cualquier
conjunto de bits dentro del campo Etiqueta de Flujo adecuado para el
uso como una clave por los enrutadores, para buscar el estado
asociado con el flujo.
Deben enviarse todos los paquetes que pertenecen al mismo flujo con
la misma direccin origen, direccin destino, y etiqueta de flujo. Si
alguno de esos paquetes incluye una cabecera Opciones de Salto a
Salto, entonces todos ellos deben originarse con los mismos
contenidos de cabecera Opciones de Salto a Salto (excepto el campo
Cabecera Siguiente de la cabecera Opciones de Salto a Salto). Si
alguno de esos paquetes incluye una cabecera Enrutamiento, entonces
todos ellos deben originarse con los mismos contenidos en todas las
cabeceras de extensin e incluso la cabecera Enrutamiento (excepto el
campo Cabecera Siguiente en la cabecera Enrutamiento). Se permiten a
los enrutadores o destinos, pero no se exige, verificar que estas
condiciones se cumplen. Si una violacin se detecta, debe reportarse
al origen en un mensaje ICMP Problema de Parmetro, Cdigo 0,
apuntando al octeto de mayor orden del campo Etiqueta de Flujo (es
decir, desplazamiento 1 dentro del paquete IPv6).
El tiempo de vida mximo de cualquier flujo en estado de tratamiento
establecido a lo largo de la ruta de un flujo debe especificarse como
parte de la descripcin del estado del mecanismo de establecimiento,
por ejemplo, el protocolo reservacin de recurso o la configuracin
de la opcin de salto a salto de flujo. Un origen no debe reusar una
etiqueta de flujo para un nuevo flujo dentro del tiempo de vida
mximo de cualquier flujo en estado de tratamiento que se podra
haber establecido para el uso anterior de esa etiqueta de flujo.
Deering & Hinden
RFC 2460
Track de Estndares
[Pgina 30]
Diciembre 1998
Cuando un nodo detiene y reinicia (por ejemplo, como resultado de una

"cada"), debe tener el cuidado de no usar una etiqueta de flujo que
podra haber usado para un flujo anterior cuyo tiempo de vida pueda
no haber expirado an. Esto puede lograrse registrando el uso de las
etiquetas de flujo sobre un almacenamiento estable para que pueda
tenerse presente durante las cadas, o abstenindose de usar
cualquier etiqueta de flujo hasta que el tiempo de vida mximo de
cualquier posible flujo previamente establecido haya expirado. Si se
conoce el tiempo mnimo para reinicializar el nodo, ese tiempo puede
descontarse del periodo de espera necesario antes de empezar a
asignar las etiquetas de flujo.

No hay ningn requisito que todos, o incluso la mayora, de los
paquetes pertenezcan a flujos, es decir, que lleven etiquetas de
flujo no cero. Esta observacin se pone aqu para recordar a los
diseadores e implementadores de protocolos no asumir lo contrario.
Por ejemplo, sera desacertado disear un enrutador cuyo rendimiento
slo sera adecuado si la mayora de los paquetes pertenecieran a
flujos, o disear un esquema de compresin de cabecera que slo
trabaje sobre paquetes que pertenezcan a flujos.
Deering & Hinden

RFC 2460
Track de Estndares
[Pgina 31]
Diciembre 1998
Apndice B. Pautas de Formateo para las Opciones

Este apndice da algunos consejos en cmo disponer los campos al
disear nuevas opciones para ser usadas en la cabecera Opciones de
Salto a Salto o en la cabecera Opciones de Destino, tal como se
describe en la seccin 4.2. Estas pautas se basan en las siguientes
suposiciones:
o Una caracterstica deseable es que cualquier campo multiocteto
dentro del rea Datos de la Opcin de una opcin se alinean en

sus lmites naturales, es decir, los campos de ancho de n
octetos deben ser colocados en un entero mltiplo de n octetos
desde el inicio de la cabecera Opciones de Salto a Salto o de
la cabecera Opciones de Destino, para n = 1, 2, 4, o 8.
o Otra caracterstica deseable es que la cabecera Opciones de
Salto a Salto o la cabecera Opciones de Destino ocupe tan poco
espacio como sea posible, sujeto al requisito que la cabecera
sea un entero mltiplo de 8 octetos de largo.
o Puede asumirse que, cuando ambas cabeceras que tienen opciones
estn presentes, llevan un nmero muy pequeo de opciones,
usualmente solo una.
Estas suposiciones sugieren la siguiente propuesta para disponer los
campos de una opcin: ordenar los campos desde el ms pequeo hasta
el ms grande, sin relleno interior, luego deducir el requisito de
alineacin para la opcin entera en base al requisito de alineacin
del campo ms grande (hasta una alineacin mxima de 8 octetos). Esta
propuesta se ilustra en los siguiente ejemplos:
Ejemplo 1
Si una opcin X requiere dos campos datos, uno de longitud de 8
octetos y uno de longitud de 4 octetos, se dispondran tal como
sigue:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Tipo d Opcin=X|Lon Dats Opc=12|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
campo de 4 octetos
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+
campo de 8 octetos
+
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Deering & Hinden

RFC 2460
Track de Estndares
[Pgina 32]
Diciembre 1998
Su requisito de alineacin es 8n+2, para asegurar que el campo de 8

octetos comience en un desplazamiento mltiplo de 8 a partir del
inicio de la cabecera circundante. Una cabecera Opciones de Salto a
Salto completa o una cabecera Opciones de Destino completa que
contiene esta nica opcin se vera como sigue:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Cabcera Siguien| Lon Cab Ext=1 |Tipo d Opcin=X|Lon Dats Opc=12|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
campo de 4 octetos
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+
campo de 8 octetos
+
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ejemplo 2
Si una opcin Y requiere tres campos datos, una de longitud de 4
octetos, una de longitud de 2 octetos, y una de longitud de 1 octeto,
se dispondran tal como sigue:
+-+-+-+-+-+-+-+-+
|Tipo d Opcin=Y|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Lon Datos Opc=7|campo d 1 octet|
campo de 2 octetos
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
campo de 4 octetos
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Su requisito de alineacin es 4n+3, para asegurar que el campo de 4
octetos comience en un desplazamiento mltiplo de 4 a partir del
inicio de la cabecera circundante. Una cabecera Opciones de Salto a
Salto completa o una cabecera Opciones de Destino completa que
contiene esta nica opcin se vera como sigue:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Cabcera Siguien| Lon Cab Ext=1 | Opcin Pad1=0 |Tipo d Opcin=Y|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
campo de 2 octetos
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
campo de 4 octetos
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcin PadN=1 |Lon Datos Opc=2|
0
|
0
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Deering & Hinden

RFC 2460
Track de Estndares
[Pgina 33]
Diciembre 1998
Ejemplo 3
Una cabecera Opciones de Salto a Salto o una cabecera Opciones de
Destino que contiene ambas opciones X e Y de los Ejemplos 1 y 2
tendra uno de los dos siguientes formatos, dependiendo en que opcin
apareciera primero:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Cabcera Siguien| Lon Cab Ext=3 |Tipo d Opcin=X|Lon Dats Opc=12|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
campo de 4 octetos
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+
campo de 8 octetos
+
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0
|Tipo d Opcin=Y|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
campo de 2 octetos
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
campo de 4 octetos
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0
|
0
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Cabcera Siguien| Lon Cab Ext=3 | Opcin Pad1=0 |Tipo d Opcin=Y|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
campo de 2 octetos
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
campo de 4 octetos
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0
|
0
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
0
|
0
|Tipo d Opcin=X|Lon Dats Opc=12|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
campo de 4 octetos
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+
campo de 8 octetos
+
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Deering & Hinden

RFC 2460
Track de Estndares
[Pgina 34]
Diciembre 1998
Consideraciones de Seguridad
Las caractersticas de seguridad del IPv6 se describen en la
Arquitectura de Seguridad para el Protocolo Internet [RFC-2401].
Reconocimientos
Los autores agradecidamente reconocen el gran nmero de sugerencias

tiles de los miembros del grupo de trabajo IPng, del grupo de
investigacin de Protocolos de Extremo a Extremo, y de la Comunidad
Internet En General.
Direcciones de los Autores
Stephen E. Deering
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
Telfono:
+1 408 527 8213
Fax:
+1 408 527 8254
Correo Electrnico: deering@cisco.com
Robert M. Hinden
Nokia
232 Java Drive
Sunnyvale, CA 94089
USA
Telfono:
+1 408 990-2004
Fax:
+1 408 743-5677
Correo Electrnico: hinden@iprg.nokia.com
Direccin del Traductor al Castellano
Percy Luis Ch Castillo
UPAO
Av. Amrica Sur 3145
Urb. Monserrate, Trujillo
PER
Telfono:
+51 044 201880
Fax:
+51 044 286111
Correo Electrnico: percychecastillo@yahoo.com
Deering & Hinden

RFC 2460
Track de Estndares
[Pgina 35]
Diciembre 1998
Referencias
[RFC-2401] Kent, S. y R. Atkinson, "Arquitectura de Seguridad para
el Protocolo Internet", RFC 2401, Noviembre 1998.
[RFC-2402] Kent, S. y R. Atkinson, "Cabecera Autenticacin del IP",

RFC 2402, Noviembre 1998.
[RFC-2406] Kent, S. y R. Atkinson, "Seguridad del Encapsulado de la
Carga til (ESP)", RFC 2406, Noviembre 1998.
[ICMPv6]
Conta, A. y S. Deering, "ICMP para el Protocolo Internet
Versin 6 (IPv6)", RFC 2463, Diciembre 1998.
[ADDRARCH] Hinden, R. y S. Deering, "Arquitectura de
Direccionamiento para la Versin 6 del IP", RFC 2373,
Julio 1998.
[RFC-1981] McCann, J., Mogul, J. y S. Deering, "Descubrimiento de
la MTU para la versin 6 del IP", RFC 1981, Agosto 1996.
[RFC-791] Postel, J., "Protocolo Internet", STD 5, RFC 791,
Setiembre 1981.
[RFC-1700] Reynolds, J. y J. Postel, "Nmeros Asignados", STD 2,
RFC 1700, Octubre 1994. Ver tambin:
http://www.iana.org/numbers.html
[RFC-1661] Simpson, W., "El Protocolo Punto a Punto (PPP)", STD
51, RFC 1661, Julio 1994.
CAMBIOS A PARTIR DE LA RFC-1883
Este memorndum tiene los siguientes cambios a partir de la RFC-1883.
Los nmeros identifican la versin del Bosquejo Internet en la cual
se hizo el cambio.
02) Se quitaron todas las referencias a datagramas de tamao gigante
y la opcin Carga til de Tamao Gigante (se movi hacia un
documento separado).
02) Se movi la mayor parte de la descripcin de la Etiqueta de
Flujo de la seccin 6 hacia el (nuevo) Apndice A.
02) En la descripcin de la Etiqueta de Flujo, ahora en el Apndice
A, se corrigi el valor Etiqueta de Flujo mximo de FFFFFF a
FFFFF (es decir, un "F" menos) debido a la reduccin del tamao
del campo Etiqueta de Flujo de 24 bits a 20 bits.
Deering & Hinden

RFC 2460
Track de Estndares
[Pgina 36]
Diciembre 1998
02) Se reenumer (se reletre?) el anterior Apndice A para ser el

Apndice B.
02) Se cambi la redaccin de la seccin Consideraciones de
Seguridad para evitar bucle dependencia entre esta

especificacin y las especificaciones del IPsec.
02) Se actualiz la direccin de correo electrnico y la afiliacin
de compaa de R. Hinden.
-------------------------------------------------------01) En la seccin 3, se cambi el nombre del campo "Clase" a "Clase
de Trfico" y se aument su tamao de 4 a 8 bits. Se disminuy
el tamao del campo Etiqueta de Flujo de 24 a 20 bits para
compensar el aumento en el campo Clase de Trfico.
01) En la seccin 4.1, se restituy el orden de la Cabecera
Autenticacin y la Cabecera ESP, las cuales fueron
intercambiadas equivocadamente en la versin 00 de este
memorndum.
01) En la seccin 4.4, se suprimi el campo Mapa de Bits
Estricto/Impreciso y la funcionalidad enrutamiento estricto de
la cabecera Enrutamiento de Tipo 0, y se quit la restriccin
sobre el nmero de direcciones que pueden ser llevadas dentro de
la cabecera Enrutamiento de Tipo 0 (fue limitado a 23
direcciones, debido al tamao del mapa de bits
estricto/impreciso).
01) En la seccin 5, se cambi la mnima MTU IPv6 de 576 a 1280
octetos, y se aadi una recomendacin que los enlaces con una
MTU configurable (por ejemplo, enlaces PPP) sean configurados
para tener una MTU de por lo menos 1500 octetos.
01) En la seccin 5, se suprimi el requisito que un nodo no debe
enviar paquetes fragmentados de tal manera que reensamblan a ms
de 1500 octetos sin conocimiento del tamao del bfer de
reensamblaje destino, y se lo reemplaz con una recomendacin
que los protocolos o las aplicaciones de capa superior no
deberan hacer eso.
01) Se reemplaz la referencia hacia la especificacin
Descubrimiento de la MTU de la Ruta para el IPv4 (RFC-1191) con
la referencia hacia la especificacin Descubrimiento de la MTU
de la Ruta para el IPv6 (RFC-1981), y se suprimieron las Notas
al final de la seccin 5 respecto al Descubrimiento de la MTU de
la Ruta, dado que esos detalles ahora son cubiertos por la RFC1981.
Deering & Hinden
RFC 2460
Track de Estndares
[Pgina 37]
Diciembre 1998
01) En la seccin 6, se suprimi la especificacin de flujo

establecido "oportunista", y se quitaron todas las referencias
al tiempo de vida mximo de 6 segundos para el estado de flujo
establecido oportunamente.
01) En la seccin 7, se suprimi la descripcin provisional de la
estructura interna y semntica del campo Clase de Trfico, y se
especific que tales descripciones sean proporcionadas en
documentos separados.
-------------------------------------------------------00) En la seccin 4, se corrigi el valor Cdigo para indicar
"encontrado tipo de Cabecera Siguiente desconocido" en un
mensaje ICMP Problema de Parmetro (se cambi de 2 a 1).
00) En la descripcin del campo Longitud de la Carga til en la
seccin 3, y del campo Longitud de la Carga til de Tamao
Gigante en la seccin 4.3, se aclar que las cabeceras de
extensin estn incluidas en el conteo de la longitud de la
carga til.
00) En la seccin 4.1, se intercambi el orden de la cabecera
Autenticacin y la cabecera ESP. (NOTA: esto fue un error, y el
cambio fue desecho en la versin 01).
00) En la seccin 4.2, se aclar que las opciones son identificadas
por un Tipo de Opcin de 8 bits completo, no por los 5 bits de
bajo orden de un Tipo de Opcin. Se especific tambin que el
mismo espacio de enumeracin del Tipo de Opcin es usado tanto
por la cabecera Opciones de Salto a Salto como por la cabecera
Opciones de Destino.
00) En la seccin 4.4, se aadi una sentencia exigiendo que los
nodos que procesan una cabecera Enrutamiento deben enviar un
mensaje ICMP Paquete Demasiado Grande en contestacin a un
paquete que es demasiado grande para caber en el enlace de salto
siguiente (en lugar de, digamos, llevar a cabo fragmentacin).
00) Se cambi el nombre del campo Prioridad IPv6 a "Clase", y se
reemplaz la descripcin anterior de Prioridad en la seccin 7
con una descripcin del campo Clase. Tambin, se excluy este
campo del conjunto de campos que deben permanecer de la misma
forma para todos los paquetes en el mismo flujo, tal como se
especific en la seccin 6.
Deering & Hinden

RFC 2460
Track de Estndares
[Pgina 38]
Diciembre 1998
00) En la pseudo cabecera en la seccin 8.1, se cambi el nombre del

campo "Longitud de la Carga til" a "Longitud del Paquete de
Capa Superior". Se aclar tambin que, en el caso de protocolos

que llevan su propia informacin de longitud (como el datagrama
de tamao no gigante UDP), es la longitud derivada de la capa
superior, no la longitud derivada de la capa IP, la que es usada
en la pseudo cabecera.
00) Se aadi la seccin 8.4, especificando que los protocolos de
capa superior, al contestar a un paquete recibido que llev una
cabecera Enrutamiento, no deben incluir el inverso de la
cabecera Enrutamiento en el(los) paquete(s) respuesta a menos
que la cabecera Enrutamiento recibida fuese autenticada.
00) Corregidos algunos errores tipogrficos y errores gramaticales.
00) Actualizada la informacin de contacto de los autores.
-------------------------------------------------------Declaracin de Copyright Completa
Copyright (C) La Sociedad Internet (1998). Todos los Derechos
Reservados.
Este documento y sus traducciones puede ser copiado y facilitado a
otros, y los trabajos derivados que lo comentan o lo explican o
ayudan a su implementacin pueden ser preparados, copiados,
publicados y distribuidos, enteros o en parte, sin restriccin de
ningn tipo, siempre que se incluyan este prrafo y el aviso de
copyright expuesto arriba en todas esas copias y trabajos
derivados. Sin embargo, este documento en s no debe ser modificado
de ninguna forma, tal como eliminando el aviso de copyright o
referencias a la Sociedad Internet u otras organizaciones de
Internet, excepto cuando sea necesario en el desarrollo de estndares
Internet, en cuyo caso se seguirn los procedimientos para
copyrights definidos en el proceso de Estndares Internet, o con
motivo de su traduccin a otras lenguas aparte del Ingls.
Los permisos limitados concedidos ms arriba son perpetuos y no sern
revocados por la Sociedad Internet o sus sucesores o cesionarios.
Este documento y la informacin contenida en l se proporcionan en su
forma "TAL CUAL" y LA SOCIEDAD INTERNET Y LA FUERZA DE TRABAJO EN
INGENIERA INTERNET RECHAZAN CUALESQUIERA GARANTAS, EXPRESAS O
IMPLCITAS, INCLUYENDO, PERO NO LIMITADAS A, CUALQUIER GARANTA DE
QUE EL USO DE LA INFORMACIN AQU EXPUESTA NO INFRINGIR NINGN
DERECHO O GARANTAS IMPLCITAS DE COMERCIALIZACIN O IDONEIDAD PARA
UN PROPSITO ESPECFICO.
Deering & Hinden
Netgarafa:
Track de Estndares
[Pgina 39]
http://www.rfc-es.org/rfc/rfc0791-es.txt
http://www.rfc-es.org/rfc/rfc2460-es.txt

RFC

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

RFC

Загружено:

Авторское право:

Доступные форматы

RFC: 791

2. PANORAMA GENERAL ................................................. 5

Relacin con Otros Protocolos ................................. 9

la parte de datos de un datagrama internet. El mdulo TCP

internet creara entonces un datagrama internet y utilizara la

ser usada por las pasarelas para seleccionar los parmetros de

utilizar para el siguiente salto, o la siguiente pasarela al

Enva este datagrama y la direccin de red local a la interfaz de

Esta interfaz de red local crea una cabecera de red local y le

interpretacin de una direccin internet. Por eso, un importante

ruta indica cmo llegar all. El protocolo internet maneja

La fragmentacin de un datagrama internet es necesaria cuando ste

local invisible para el mdulo del protocolo internet se llama

segundo trozo de datos es colocado en el segundo nuevo datagrama

protocolo internet (por ejemplo en un host de destino) combina todos

del trfico (generalmente aceptando slo trfico por encima de

Bits 6-7: Reservado para uso futuro.

El uso de las indicaciones de Retraso, Rendimiento y fiabilidad

esa red controlar el acceso a, y el uso de, esos modos de

datagramas de tal longitud no son prcticos para la mayora de hosts

La posicin del fragmento se mide en unidades de 8 octetos (64

cero, entonces el datagrama debe ser destrudo. Este campo es

La direccin de destino. Ver seccin 3.2.

opcional es su transmisin en cualquier datagrama en particular, no

Se definen las siguientes opciones de internet:

(TCC), y Cdigos de Manejo de Restricciones

Definiciones de Opciones Especficas

Compartimentos (Campo C): 16 bits

de todo ceros. Otros valores para el campo Compartimentos

puntero es mayor que la longitud, la ruta de origen est vaca

el campo de la direccin de destino.

octeto en el cual comienza la siguiente direccin de origen a

procesar. El puntero es relativo a esta opcin, y su menor valor

La opcin comienza con el cdigo de tipo de opcin. El segundo

cualquier tiempo como marca de tiempo, siempre que el bit de

Un valor cero en el campo de red indica la red actual. Slo se usa

ARPANET, SATNET, PRNET y otras redes se describen en

Si el indicador "Don't Fragment" (No Fragmentar) (DF) est a uno,

fragmentacin en casos donde el host receptor no dispone de

entonces se asignan recursos de reensamblaje. Los recursos de

- Posicin del Fragmento ("Fragment Offset")

BUFID - Identificador de buffer (Buffer Identifier)

tienen el mismo origen, destino, protocolo e Identificador. De este

modo el remitente debe elegir un Identificador que sea nico para

no controlados tienden a ser entregados con menos fiabilidad y a

enviar a travs de ARPANET. Sea el tipo de servicio internet dado

Las opciones pueden no ocupar exactamente un espacio mltiplo de 32

el mdulo internet. Como el protocolo internet es un protocolo de

el IP ejecute el servicio pedido.

opt = datos de opcin

mensaje. Si los argumentos son vlidos y el datagrama es aceptado por

APENDICE A: Ejemplos y Escenarios

Ahora el primer fragmento resultado de dividir el datagrama a los 256

APPENDICE B: Orden de Transmisin de Datos

De forma similar, cuando un campo multiocteto representa una cantidad

BBN Report 1822, "Especificacin de la Interconexin de un

El bit 'Don't Fragment' (No Fragmentar) del campo de

Gateway to Gateway Protocol (Protocolo Pasarela a Pasarela),

Control de Internet), implementado en el mdulo internet, el

El campo de la cabecera internet 'Internet Header Length'

Number of Fragment Blocks (Nmero de Bloques de Fragmento) en

Type of Service (Tipo de Servicio)

Time to Live (Tiempo de Vida)