Para recordar (2)

Hay que tener presentes los protocolos y procesos de la capa de aplicación; Telnet es un programa de emulación de terminal que te permite entrar a un host remoto y ejecutar programas. FTP es un servicio orientado a conexión que permite transferir archivos. TFTP es un servicio orientado a no conexión que también transfiere archivos. SMTP es un programa que permite enviar correo.

Los protocolos de la capa de host-to-host (transporte) son TCP, que es orientado a conexión y nos da un servicio de red confiable por medio del uso de acknowledgements y control de flujo. UDP es un protocolo sin conexión que con un overhead pequeño nos da un servicio considerado no confiable.

Los protocolos de la capa de Internet son IP, que es un protocolo no orientado a conexión que provee direccionamiento de red y enrutamiento a través de una red. ARP que encuentra direcciones MAC para una IP conocida. RARP que encuentra la IP de una MAC address conocida. ICMP provee diagnóstico y mensajes de estado de los destinos buscados.

Los rangos de clase de las direcciones IP:
Clase A, de 1.0.0.0 a 126.255.255.255 con 8 bits de red y 24 bits de host.
Clase B, de 128.0.0.0 a 191.255.255.255 con 16 bits de red y 16 bits de host.
Clase C, de 192.0.0.0 a 223.255.255.255 con 24 bits de red y 8 bits de host.

Los rangos de direccionamiento privados;
de 10.0.0.0 a 10.255.255.255
de 172.16.0.0 a 172.31.255.255
de 192.168.0.0 a 192.168.255.255

Recordemos que la dirección 127.0.0.1 está asignada al host local, es la dirección de loopback y es usada para diagnósticos sobre el funcionamiento de nuestro propio stack de TCP, cuando hacemos un ping a esta dirección, el paquete no llega a la interfase física.

Mapa de protocolos

He notado que muchas personas se preguntan, ¿en qué capa del modelo OSI se encuentra X protocolo?, o ¿cuáles son los protocolos de la capa de aplicación? o ¿de la capa de transporte?

Bueno, he aquí un mapa con los principales protocolos de red y su ubicación dentro del modelo de referencia OSI:

*update: faltó mencionar Frame Relay en la capa de enlace de datos (Data Link) junto a ATM

Encapsulamiento IP

Tomaré el ejemplo del post anterior para explicar los campos contenidos en este datagrama de IP, sin tomar en cuenta el encabezado Ethernet, que fue explicado claramente. Entonces tenemos los 60 bytes del datagrama, ordenados en grupos de 8 bytes por renglón para su fácil lectura, y con la numeración en valores hexadecimales:

000000: 45 00 00 3C 82 47 00 00 E..<.G..

000008: 20 01 94 C9 C0 A8 01 01 ......

000010: C0 A8 01 11 08 00 48 5C ...@..H\

000018: 01 00 04 00 61 62 63 64 ....abcd

000020: 65 66 67 68 69 6A 6B 6C efghijkl

000028: 6D 6E 6F 70 71 72 73 74 mnopqrst

000030: 75 76 77 61 62 63 64 65 uvwabcde

000038: 66 67 68 69 fghi

Ahora bien, ¿que es lo que nos dice esta información?

• Los primeros 4 bits nos indican que es un datagrama versión 4 (IPv4).
• El siguiente campo nos indica que tiene una longitud de 5 palabras, cada una de 4 bytes; y el mínimo es 5.
• El tipo de servicio nos indica la calidad de servicio QoS, anteriormente era el campo de precedencia y se cambió para dar lugar al etiquetado de DCSP (Differentiated Services Code Point; RFC 2474); en este caso, al ser un paquete de ICMP no tiene prioridad.
• La longitud total del datagrama, en este caso 60 bytes.
• El campo de identificación sirve para distinguir un datagrama de otro.
• Las banderas nos indican que se puede fragmentar este datagrama si fuera necesario y que es el último fragmento.
• El offset nos asegura que se utilicen los primeros 8 bytes del encabezado

Los campos subsecuentes están explicados a detalle en el post anterior.

Ejemplo de Encapsulamiento (ilustración del datagrama)

Tomando el caso del ejemplo anterior, el datagrama será analizado en fragmentos de 8 bytes, indicando la longitud de cada campo; recordemos que es un paquete de ICMP encapsulado en IP.

Del byte 0 al 7:

y tenemos la siguiente información de sus campos:



IHL: Especifica la longitud del encabezado de IP en palabras de 32 bits (4 Bytes) y el valor mínimo es 5.

TOS: Type of service, 8 bits, especifica los parámetros para el tipo de servicio solicitado. Los parámetros pueden ser utilizados por las redes para defini el manejo del datagrama durante el transporte. El bit M fue agregado en el RFC 1349.



Total Lenght: es la longitud total del datagrama, en este caso es 0x003C (60 bytes).

Identification: Usado para indentificar fragmentos de un datagrama deaquellos de otro. El módulo de protocolo que origina al datagrama fija el valor del campo de identificación a un valor que debe ser único para el par de Fuente-Destino y protocolo por todo el tiempo que el datagrama estará activo en el sistema de red. El módulo de protocolo de origen de un datagrama completo pone los bits MF y el Fragment Offset a cero.



Fragment Offset, 13 bits: usado para dirigir el reensamblado de un datagrama fragmentado. En este caso es cero porque no hay más fragmentos.

Del byte 8 al 15:

TTL: Time to live, es un temporizador para llevar un control del tiempo de vida del datagrama. Cuando el TTL es decrementado a cero, el datagrama es desechado.

Protocol: este campo especifica el protocolo encapsulado, en este caso el valor es 1, lo que nos indica que se trata de un paquete de ICMP (ping). Consulta los valores en la tabla (click aquí).

Header Checksum: 16 bits de la suma de verificación del encabezado de IP y las opciones IP.

Source IP Address: Es la dirección IP del transmisor, en este caso 192.168.1.1 (0xC0.A8.01.01).

Del byte 16 al 27:

Destination IP Address: es la dirección IP del destino, en este caso 192.168.1.17 (0xC0.A8.01.11).

C, Class y Option: en este caso indican (tabla de valores):

• 0x0: no copiar


• 0x00: mensaje de control


• 0x1000: solicitud de Echo (RFC 792, Summary of Message Types, 8 Echo).

Padding: es de longitud variable y sirve como relleno para asegurar que los datos comienzan tras de una frontera de 32 bits después de la dirección de destino.

Aquí es importante destacar que al tratarse de un mensaje de control (ICMP) se utilizan los bytes del 20 al 27 para información de control; y se usan de la siguiente manera (RFC792):

    20                  21                  22                  23
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       Type           Code                Checksum            
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             Identifier                  Sequence Number       
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       Data ...

  +-+-+-+-+-

De aquí obtenemos que:

• byte 20, es un paquete tipo 8 (echo request)
• byte 21, siempre va a cero
• byte 22 y 23, es el checksum de ICMP
• bytes 24 y 25, si el byte 21=0 el identificador ayuda a hacer match entre las solicitudes y las respuestas de eco; puede ser 0 o puede usarse para identificar una sesión.
• bytes 26 y 27 son para llevar la secuencia de las solicitudes de eco, y quien responde debe usar el mismo número; la secuencia debe incrementarse con cada nueva solicitud (en una instrucción típica de ping se envían 4 paquetes, y pueden enviarse cuantos se desee).

Bytes del 28 al 59 (32 bytes)

Son los datos de relleno que se colocaron dentro del mensaje de Echo, y se trata de una secuencia, del 0x61 al 0x77, y se vuelve a comenzar. Cuando se responde la solicitud de eco se debe incluir exactamente la misma información en el campo de datos.

Ejemplo de Encapsulamiento

Para comenzar, la dirección de origen usada 192.168.1.1 se escribe así en hexadecimal: C0 A8 01 01

Cuando escribimos el comando:

C:\>ping 192.168.1.1

Este es el paquete de Ping (74 Bytes)como aparece en la red Ethernet, y cada par de números representa un byte (8 bits) de información dentro del frame o paquete:

[sourcecode language='css']
000000: 00 A0 CC 63 08 1B 00 40 : 95 49 03 5F 08 00 45 00 ...c...@.I._..E.

000010: 00 3C 82 47 00 00 20 01 : 94 C9 C0 A8 01 01 C0 A8 .<.G.. ...... ..

000020: 01 11 08 00 48 5C 01 00 : 04 00 61 62 63 64 65 66 .@..H\....abcdef

000030: 67 68 69 6A 6B 6C 6D 6E : 6F 70 71 72 73 74 75 76 ghijklmnopqrstuv

000040: 77 61 62 63 64 65 66 67 : 68 69 wabcdefghi......

[/sourcecode]

donde tenemos que los primeros 14 bytes componen el encabezado Ethernet, y son:

• 00 A0 CC 63 08 1B la dirección MAC de destino
• 00 40 95 49 03 5F la dirección MAC de origen
• 08 00 el campo Tipo de Ethernet (0x0800 IP Datagram)

sigue el datagrama de IP (60 Bytes), que ya sin el encapsulado de Ethernet nos queda así:

[sourcecode language='css']
000000: 45 00 00 3C 82 47 00 00 : 20 01 94 C9 C0 A8 01 01 E..<.G.. ......

000010: C0 A8 01 11 08 00 48 5C : 01 00 04 00 61 62 63 64 ...@..H\....abcd

000020: 65 66 67 68 69 6A 6B 6C : 6D 6E 6F 70 71 72 73 74 efghijklmnopqrst

000030: 75 76 77 61 62 63 64 65 : 66 67 68 69 uvwabcdefghi......

[/sourcecode]

y comienza con un valor 0x4500, el 4 indica que es un paquete de IPv4 y el 5 que el encabezado de IP tiene una longitud de 5 palabras de 32 bits; es decir, 160 bits o 20 bytes.

tenemos una dirección de origen 192.168.1.1 (C0 A8 01 01)
y una dirección de destino 192.168.1.17 (C0 A8 01 11)

y nos quedan 40 bytes de datos IP, que en este caso son de una solicitud de eco (ICMP Echo Request), incluyendo 32 bytes de datos (longitud por default para un paquete de ping).

Este post es un complemento al anterior:

http://ipref.wordpress.com/2008/06/03/encapsulamiento/

y posteriormente pondré una descripción detallada de cada uno de los números presentes en el frame de ejemplo.

Three-way handshake

del artículo de Microsoft:
Explanation of the Three-Way Handshake via TCP/IP

El nivel del protocolo de transporte comprendido en TCP (transport control protocol) es orientado a conexión; lo que significa que antes de poder transmitir datos, se debe obtener una conexión confiable y reconocida (con acknowledge). Las transmisiones de datos a nivel TCP, los establecimientos de conexión y terminación de conexión, mantienen parámetros específicos de control que gobiernan el proceso completo. Los bits de control son:

• URG: Urgent Pointer field significant
• ACK: Acknowledgement field significant
• PSH: Push Function
• RST: Reset the connection
• SYN: Synchronize sequence numbers
• FIN: No more data from sender

Hay dos escenarios donde un proceso de three-way handshake tendrá lugar:

• Estableciendo una conexión (apertura activa)
• Terminando una conexión (cierre activo)

La información de muestra fue obtenida de un captura de un Monitor de red (analizador de protocolos que puede obtenerse de un Microsoft Systems Management Server).

Estableciendo una conexión

La siguiente secuencia muestra el proceso de una conexión de TCP siendo establecida:

Frame1:

Como podemos ver en el primer frame, el cliente NTW3 envía un segmento SYN (TCP…S); esto es una petición al servidor para sincronizar los números de secuencia. Especifica el número de secuencia inicial (ISN) que se incrementa por 1 (8221821+1=8221822) y es enviado al servidor. Para iniciar una conexión, el cliente y el servidor deben sincronizar sus respectivos números de secuencia. También hay una opción para el tamaño máximo de segmento (MSS) que debe acordarse, y se define en la longitud (length, len: 4). Esta opción comunica el tamaño máximo de segmento que el transmisor quiere recibir. El campo de reconocimiento o acuse de recibo (acknowledge, ack: 0) se fija en cero porque es la primera parte del proceso de three-way handshake.
[sourcecode language='css']
1 2.0785 NTW3 --> BDC3 TCP ....S., len: 4, seq: 8221822-8221825, ack: 0,
win: 8192, src: 1037 dst: 139 (NBT Session) NTW3 --> BDC3 IP

TCP: ....S., len: 4, seq: 8221822-8221825, ack: 0, win: 8192, src: 1037
dst: 139 (NBT Session)

TCP: Source Port = 0x040D
TCP: Destination Port = NETBIOS Session Service
TCP: Sequence Number = 8221822 (0x7D747E)
TCP: Acknowledgement Number = 0 (0x0)
TCP: Data Offset = 24 (0x18)
TCP: Reserved = 0 (0x0000)
TCP: Flags = 0x02 : ....S.

TCP: ..0..... = No urgent data
TCP: ...0.... = Acknowledgement field not significant
TCP: ....0... = No Push function
TCP: .....0.. = No Reset
TCP: ......1. = Synchronize sequence numbers
TCP: .......0 = No Fin

TCP: Window = 8192 (0x2000)
TCP: Checksum = 0xF213
TCP: Urgent Pointer = 0 (0x0)
TCP: Options

TCP: Option Kind (Maximum Segment Size) = 2 (0x2)
TCP: Option Length = 4 (0x4)
TCP: Option Value = 1460 (0x5B4)

TCP: Frame Padding

00000: 02 60 8C 9E 18 8B 02 60 8C 3B 85 C1 08 00 45 00 .`.....`.;....E.
00010: 00 2C 0D 01 40 00 80 06 E1 4B 83 6B 02 D6 83 6B .,..@....K.k...k
00020: 02 D3 04 0D 00 8B 00 7D 74 7E 00 00 00 00 60 02 .......}t~....`.
00030: 20 00 F2 13 00 00 02 04 05 B4 20 20 .........

[/sourcecode]
Frame 2:

En el segundo frame, el servidor BDC3 envía un ACK y un SYN en este segmento (TCP .A..S.) En este segmento el servidor está acusando de recibida la petición del cliente para sincronizar. Al mismo tiempo, el servidor también envía su petición al cliente para sincronizar sus números de secuencia. Hay una diferencia importante en este segmento. El servidor transmite un número de acuse (acknowledgement number 8221823) al cliente. El acknowledgement es sólo la prueba para que el cliente sepa que el ACK es la respuesta al SYN que el cliente inició. El proceso de acuse de recibo que el cliente requirió permite al servidor incrementar el número de secuencia del cliente por uno y lo usa como su número de acknowledgement.

[sourcecode language='css']
2 2.0786 BDC3 --> NTW3 TCP .A..S., len: 4, seq: 1109645-1109648, ack:
8221823, win: 8760, src: 139 (NBT Session) dst: 1037 BDC3 --> NTW3 IP

TCP: .A..S., len: 4, seq: 1109645-1109648, ack: 8221823, win: 8760,
src: 139 (NBT Session) dst: 1037

TCP: Source Port = NETBIOS Session Service
TCP: Destination Port = 0x040D
TCP: Sequence Number = 1109645 (0x10EE8D)
TCP: Acknowledgement Number = 8221823 (0x7D747F)
TCP: Data Offset = 24 (0x18)
TCP: Reserved = 0 (0x0000)
TCP: Flags = 0x12 : .A..S.

TCP: ..0..... = No urgent data
TCP: ...1.... = Acknowledgement field significant
TCP: ....0... = No Push function
TCP: .....0.. = No Reset
TCP: ......1. = Synchronize sequence numbers
TCP: .......0 = No Fin

TCP: Window = 8760 (0x2238)
TCP: Checksum = 0x012D
TCP: Urgent Pointer = 0 (0x0)
TCP: Options

TCP: Option Kind (Maximum Segment Size) = 2 (0x2)
TCP: Option Length = 4 (0x4)
TCP: Option Value = 1460 (0x5B4)

TCP: Frame Padding

00000: 02 60 8C 3B 85 C1 02 60 8C 9E 18 8B 08 00 45 00 .`.;...`......E.
00010: 00 2C 5B 00 40 00 80 06 93 4C 83 6B 02 D3 83 6B .,[.@....L.k...k
00020: 02 D6 00 8B 04 0D 00 10 EE 8D 00 7D 74 7F 60 12 ...........}t`.
00030: 22 38 01 2D 00 00 02 04 05 B4 20 20 "8.-......

[/sourcecode]
Frame 3:
En el tercer frame, el cliente envía un ACK en el segmento (TCP .A….) y el cliente está confirmando la petición del servidor para sincronizar. El cliente usa el mismo algoritmo que el servidor implementó para dar un número de confirmación. La confirmación del cliente está completando el proceso de establecer una conexión confiable, a través del Three-Way Handshake.
[sourcecode language='css']
3 2.787 NTW3 --> BDC3 TCP .A...., len: 0, seq: 8221823-8221823, ack:
1109646, win: 8760, src: 1037 dst: 139 (NBT Session) NTW3 --> BDC3 IP

TCP: .A...., len: 0, seq: 8221823-8221823, ack: 1109646, win: 8760,
src: 1037 dst: 139 (NBT Session)

TCP: Source Port = 0x040D
TCP: Destination Port = NETBIOS Session Service
TCP: Sequence Number = 8221823 (0x7D747F)
TCP: Acknowledgement Number = 1109646 (0x10EE8E)
TCP: Data Offset = 20 (0x14)
TCP: Reserved = 0 (0x0000)
TCP: Flags = 0x10 : .A....

TCP: ..0..... = No urgent data
TCP: ...1.... = Acknowledgement field significant
TCP: ....0... = No Push function
TCP: .....0.. = No Reset
TCP: ......0. = No Synchronize
TCP: .......0 = No Fin

TCP: Window = 8760 (0x2238)
TCP: Checksum = 0x18EA
TCP: Urgent Pointer = 0 (0x0)
TCP: Frame Padding

00000: 02 60 8C 9E 18 8B 02 60 8C 3B 85 C1 08 00 45 00 .`.....`.;....E.
00010: 00 28 0E 01 40 00 80 06 E0 4F 83 6B 02 D6 83 6B .(..@....O.k...k
00020: 02 D3 04 0D 00 8B 00 7D 74 7F 00 10 EE 8E 50 10 .......}t....P.
00030: 22 38 18 EA 00 00 20 20 20 20 20 20 "8....

[/sourcecode]

Terminando una conexión

Aunque el proceso three-way handshake solo requiere 3 paquetes para ser transmitido sobre nuestro medio de red, la terminación de esta conexión confiable necesitará la transmisión de 4 paquetes. Debido a que una conexión TCP es Full Duplex (fluye información en cada dirección de manera independiente de la otra) cada dirección debe ser terminada de manera independiente.

Frame 4
En esta sesión de frames, podemos ver alcliente enviando un FIN que es acompañado por un ACK (TCP.A…F) Este segmento tiene dos funciones básicas; primero, cuando el parámetro FIN es fijado, informará al servidor que no hay más datos que enviar; segundo, el ACK es esencial para identificar la conexión específica que ellos establecieron.

[sourcecode language='css']
4 16.0279 NTW3 --> BDC3 TCP .A...F, len: 0, seq: 8221823-8221823,
ack:3462835714, win: 8760, src: 2337 dst: 139 (NBT Session) NTW3 --> BDC3
IP

TCP: .A...F, len: 0, seq: 8221823-8221823, ack: 1109646, win: 8760, src:
1037 dst: 139 (NBT Session)

TCP: Source Port = 0x040D
TCP: Destination Port = NETBIOS Session Service
TCP: Sequence Number = 8221823 (0x7D747F)
TCP: Acknowledgement Number = 1109646 (0x10EE8E)
TCP: Data Offset = 20 (0x14)
TCP: Reserved = 0 (0x0000)
TCP: Flags = 0x11 : .A...F

TCP: ..0..... = No urgent data
TCP: ...1.... = Acknowledgement field significant
TCP: ....0... = No Push function
TCP: .....0.. = No Reset
TCP: ......0. = No Synchronize
TCP: .......1 = No more data from sender

TCP: Window = 8760 (0x2238)
TCP: Checksum = 0x236C
TCP: Urgent Pointer = 0 (0x0)

00000: 00 20 AF 47 93 58 00 A0 C9 22 F5 39 08 00 45 00 . .G.X...".9..E.
00010: 00 28 9B F5 40 00 80 06 21 4A C0 5E DE 7B C0 5E .(..@...!J.^.{.^
00020: DE 57 09 21 05 48 0B 20 96 AC CE 66 AE 02 50 11 .W.!.H. ...f..P.
00030: 22 38 23 6C 00 00 "8#l..

[/sourcecode]
Frame 5:
Aquí no se ve nada especial, excepto el servidor confirmando el FIN que envió el cliente.


[sourcecode language='css']
5 16.0281 BDC3 --&gt; NTW3 TCP .A...., len: 0, seq: 1109646-1109646,
ack: 8221824, win:28672, src: 139 dst: 2337 (NBT Session) BDC3 --&gt; NTW3
IP

TCP: .A...., len: 0, seq: 1109646-1109646, ack: 8221824, win:28672, src:
139 dst: 2337 (NBT Session)

TCP: Source Port = 0x040D
TCP: Destination Port = NETBIOS Session Service
TCP: Sequence Number = 1109646 (0x10EE8E)
TCP: Acknowledgement Number = 8221824 (0x7D7480)
TCP: Data Offset = 20 (0x14)
TCP: Reserved = 0 (0x0000)
TCP: Flags = 0x10 : .A....

TCP: ..0..... = No urgent data
TCP: ...1.... = Acknowledgement field significant
TCP: ....0... = No Push function
TCP: .....0.. = No Reset
TCP: ......0. = No Synchronize
TCP: .......0 = No Fin

TCP: Window = 28672 (0x7000)
TCP: Checksum = 0xD5A3
TCP: Urgent Pointer = 0 (0x0)
TCP: Frame Padding

00000: 00 A0 C9 22 F5 39 08 00 02 03 BA 84 08 00 45 00 ...".9........E.
00010: 00 28 D2 82 00 00 3F 06 6B BD C0 5E DE 57 C0 5E .(....?.k..^.W.^
00020: DE 7B 05 48 09 21 CE 66 AE 02 0B 20 96 AD 50 10 .{.H.!.f... ..P.
00030: 70 00 D5 A3 00 00 90 00 01 00 86 00 p...........

[/sourcecode]
Frame 6
Después de recibir el paquete FIN desde el cliente, el servidor confirmará. Aún cuando TCP ha establecido conexiones entre esas dos computadoras, las conexiones son aún independientes una de otra; así que el servidor debe transmitir también un paquete FIN (TCP .A…F) al cliente.


[sourcecode language='css']
6 17.0085 BDC3 --&gt; NTW3 TCP .A...F, len: 0, seq: 1109646-1109646, ack:
8221824, win:28672, src: 139 dst: 2337 (NBT Session) BDC3 --&gt; NTW3 IP

TCP: .A...F, len: 0, seq: 1109646-1109646, ack: 8221824, win:28672, src:
139 dst: 2337 (NBT Session)

TCP: Source Port = 0x0548
TCP: Destination Port = 0x0921
TCP: Sequence Number = 1109646 (0x10EE8E)
TCP: Acknowledgement Number = 8221824 (0x7D7480)
TCP: Data Offset = 20 (0x14)
TCP: Reserved = 0 (0x0000)
TCP: Flags = 0x11 : .A...F

TCP: ..0..... = No urgent data
TCP: ...1.... = Acknowledgement field significant
TCP: ....0... = No Push function
TCP: .....0.. = No Reset
TCP: ......0. = No Synchronize
TCP: .......1 = No more data from sender

TCP: Window = 28672 (0x7000)
TCP: Checksum = 0xD5A2
TCP: Urgent Pointer = 0 (0x0)
TCP: Frame Padding

00000: 00 A0 C9 22 F5 39 08 00 02 03 BA 84 08 00 45 00 ...".9........E.
00010: 00 28 D2 94 00 00 3F 06 6B AB C0 5E DE 57 C0 5E .(....?.k..^.W.^
00020: DE 7B 05 48 09 21 CE 66 AE 02 0B 20 96 AD 50 11 .{.H.!.f... ..P.
00030: 70 00 D5 A2 00 00 02 04 05 B4 86 00 p...........

[/sourcecode]
Frame 7
El cliente responde en la misma manera que el servidor, confirmando el paquete de FIN que recibió e incrementando el número de secuencia por 1.
[sourcecode language='css']
7 17.0085 NTW3 --&gt; BDC3 TCP .A...., len: 0, seq: 8221824-8221824, ack:
1109647, win: 8760, src: 2337 dst: 139 (NBT Session) NTW3 --&gt; BDC3 IP

TCP: .A...., len: 0, seq: 8221824-8221824, ack: 1109647, win: 8760, src:
2337 dst: 139 (NBT Session)

TCP: Source Port = 0x0921
TCP: Destination Port = 0x0548
TCP: Sequence Number = 8221824 (0x7D7480)
TCP: Acknowledgement Number = 1109647 (0x10EE8F)
TCP: Data Offset = 20 (0x14)
TCP: Reserved = 0 (0x0000)
TCP: Flags = 0x10 : .A....

TCP: ..0..... = No urgent data
TCP: ...1.... = Acknowledgement field significant
TCP: ....0... = No Push function
TCP: .....0.. = No Reset
TCP: ......0. = No Synchronize
TCP: .......0 = No Fin

TCP: Window = 8760 (0x2238)
TCP: Checksum = 0x236B
TCP: Urgent Pointer = 0 (0x0)

00000: 00 20 AF 47 93 58 00 A0 C9 22 F5 39 08 00 45 00 . .G.X...".9..E.
00010: 00 28 BA F5 40 00 80 06 02 4A C0 5E DE 7B C0 5E .(..@....J.^.{.^
00020: DE 57 09 21 05 48 0B 20 96 AD CE 66 AE 03 50 10 .W.!.H. ...f..P.
00030: 22 38 23 6B 00 00 "8#k..

[/sourcecode]
El cliente confirmando la notificación de FIN del servidor identifica el cierre de una conexión de TCP.

Para mayor información, referirse al RFC793, el cual describe a fondo el proceso estandarizado de establecimiento de conexión de TCP.

Movilidad IPv6

del documento de cisco: IPv6 Mobility At-a-Glance

Los objetivos de la movilidad de IPv6 son:

• no estar limitado a una ubicación
• tener siempre conectividad IP
• que sea independiente del transporte
• conexiones en roaming robustas
• movilidad de las aplicaciones
• continuidad de las aplicaciones
• que un server pueda ser un dispositivo móvil

Mobile IPv6 (MIPv6) se define en:

• RFC 3775: Mobility Support in IPv6
• RFC 3776: Using IPSec to Protect Mobile IPv6 Signalling between Mobile Nodes and Home Agents

Existen los mismos componentes básicos en MIPv6 como en MIPv4, excepto que no hay agentes externos en MIPv6.

figura 1

[caption id="" align="alignnone" width="445" caption="MIPv6"][/caption]

Acknowledgments (acuse de recibo)

La entrega confiable de datos asegura la intergidad de un chorro de datos enviados de una máquina a otra a través de un enlace de datos totalmente funcional. Así se asegura que los datos no serán duplicados o perdidos.

Para ello se utiliza una técnica que requiere que la máquina receptora se comunique con la transmisora enviando un acuse de recibo cuando recibe los datos, ésto se llama possitive acknowledgement with retransmission. El transmisor documenta cada segmento de datos que envía y comienza un contador de tiempo, y reenvía el segmento en caso de que el contador termine y no se haya recibdo un acuse de recibo de parte del receptor.



En el ejemplo vemos como se envían 3 segmentos, y entonces el receptor contesta con un ACK, y se envían otros 3 segmentos, con una falla en el segmento 5, por lo que se envía un ACK pidiendo el segmento 5, que es enviado a continuación.

[caption id="" align="alignnone" width="511" caption="Transport layer reliable delivery"][/caption]

windowing

Podemos imaginar que si la comunicación tuviera que esperar un acuse de recibo (Ack) por cada paquete se volvería muy lenta, por lo cual se cuenta con un mecanismo de ventana que aprovecha el tiempo disponible después de que el transmisor envía el segmento de datos y antes de que termine de procesar los acknowledgements del receptor, este tiempo se usa para transmitir más datos. La cantidad de segmentos de datos (medida en bytes) que se le permite al transmisor enviar sin recibir un acuse se llama ventana (window).

Así, el tamaño de la ventana controla cuanta información es enviada de un extremo a otro. Mientras, algunos protocolos cuantifican la información mediante la observación del número de paquetes, TCP/IP los mide contando el número de bytes.



Aquí tenemos una ventana de tamaño 1 y enseguida de tamaño 3.



Con una ventana de tamaño 1, el transmisor espera un acuse por cada segmento que envía antes de transmitir uno nuevo; y con el tamaño 3 espera un acuse cada 3 segmentos enviados.

Soportando las aplicaciones de TCP/IP

Además de incluir a TCP, IP, y UDP, la pila de protocolos TCP/IP incluye también aplicaciones que soportan otros servicios tales como transferencia de archivos, e-mail, ye ingreso remoto (remote login).

Algunas de las aplicaciones que TCP/IP soporta incluyen:

· Flow Control: si el transmisor está desbordando el buffer del receptor por transmitir demasiado rápido, el receptor descarta paquetes. Los acknowledgement fallidos alertan al transmisor para bajar la tasa de transferencia o dejar de transmitir.

· File Transport Protocol: FTP es un servicio confiable y orientado a la conexión que usa TCP para transferir archivos entre sistemas que soportan FTP. FTP también soporta la transferencia binaria bidireccional y transferencias de archivos ASCII.

· Trivial File Transfer Protocol: TFTP es un servicio no orientado a conexión que usa UDP. Los ruteadores usan TFTP para transferir archivos de configuración e imágenes de Cisco IOS, y para transferir archivos entre sistemas que soportamn TFTP.

· Terminar Emulation (Telnet): telnet provee la capacidad de acceder remotamente a otra computadora. Telnet permite a un usuario entrar en un host remotoy ejecutar comandos.

Los protocolos TCP/IP: soportan las aplicaciones y utilidades que abarcan el internet.

UDP, sus funciones

El protocolo User Datagram Protocol, es una expansión de las primeras versiones de la suite de protocolos de IP. Antes consistía dicha suite en TCP e IP solamente, aunque IP no era diferenciado como un servicio separado. Sin embargo, algunas aplicaciones tenían una necesidad de puntualidad más que de precisión. En otras palabras, la velocidad era más importante que la recuperación de paquetes. En transferencias de video o audio en tiempo real, unos cuantos paquetes perdidos son tolerables. Recuperar paquetes crea una excesiva saturación que reduce el desempeño.

Para acomodar este tipo de tráfico, los arquitectos de TCP rediseñaron la suite de protocolos para incluir a UDP. El direccionamiento básico y el servicio de expedición de paquetes en la capa de red era IP. TCP y UDP están en la capa de transporte arriba de IP, y ambos usan los servicios de IP.

UDP ofrece sólo servicios mínimos, no garantizados de transporte, y da a las aplicaciones acceso directo a la capa de IP. UDP es usado por aplicaciones que no requieresn el nivel de servicio de TCP, o que quieren usar servicios de comunicación tales como entrega por multidifusión o difusión, no disponibles en TCP.

TCP, sus funciones

TCP es un protocolo orientado a conexión que provee control de flujo y servicios de entrega de datos confiables.

Los servicios provistos por TCP corren en el anfitrión (host) de cualquiera de los extremos de una conexión, no en la red. Por lo tanto, TCP es un protocolo para manejar conexiones de extremo a extremo, y como una serie de conexiones de extremo a extremo pueden existir a través de una serie de conexiones punto a punto, estas conexiones extremo-extremo son llamadas circuitos virtuales. Éstas son las características de TCP:

Definiendo TCP/IP

TCP/IP se refiere a la familia completa de protocolos, de los cuales, TCP e IP son sólo dos.TCP provee transferencias transparentes de datos entre sistemas finales usando los servicios de la capa de red inferior para mover los paquetes entre los dos sistemas comunicantes. TCP es un ejemplo de protocolo de la capa de transporte. IP es un ejemplo de la protocolo de la capa de red.



Similar al modelo OSI/ISO, TCP/IP separa una suite completa de protocolosde red en un número de tareas. Cada capa corresponde a diferentes aspectos de la comunicación. Conceptualmente, es útil ver a TCP/IP como una pila de protocolos.Una pila de protocolos está organizada de tal manera que el nivel más alto de comunicación reside en la capa de arriba. Por ejemplo, la capa más alta puede negociar con las aplicaciones para distribuir tramas de audio o video, mientras que la capa más baja puede lidiar con voltajes o señales de radio. Cada capa en la pila se construye sobre los servicios de la capa inmediata inferior.