PROTOCOLOS DE INTERNET

INTRODUCCIÓN

En informática y telecomunicación, un protocolo de comunicaciones es un conjunto de reglas y normas que permiten que dos o más entidades de un sistema de comunicación se comuniquen entre ellos para transmitir información por medio de cualquier tipo de variación de una magnitud física. Se trata de las reglas o el estándar que define la sintaxis, semántica y sincronización de la comunicación, así como posibles métodos de recuperación de errores. Los protocolos pueden ser implementados por hardware, software, o una combinación de ambos en el presente documento nos habla acerca del conjunto de protocolos de las capas diseñadas por la IETF y de algunas de sus características más sobresalientes

PROTOCOLOS

PROTOCOLO ARP

El protocolo ARP es un protocolo de apoyo al nivel de red (Internet Layer) que efectúa la resolución de la dirección IP a la dirección física (dirección MAC en LAN) para los datagramas IP salientes. Está definido en el RFC-826. Existen dos tipos de paquetes ARP (Request y Reply)

Cuando una máquina (que conoce la dirección IP de otra máquina) desea conocer la dirección física de la otra máquina, difunde una trama, que contiene un paquete ARP Request, a todas las máquinas conectadas a esa red (broadcast). Con este paquete se solicita a la máquina con dirección IP que responda indicando su dirección física. Todas las máquinas reciben el paquete ARP Request, pero solamente la máquina que reconoce su dirección IP responde a dicha petición en forma de paquete ARP Reply (encapsulado en otra trama) que contiene su dirección física. Cuando la primera máquina recibe el paquete ARP Reply, usa la dirección física de otra para enviar datagramas IP (encapsulados en tramas), directamente a ella. Para reducir el envío continuo de paquetes ARP por la red, cada máquina mantiene una tabla ARP cache, donde se encuentran parejas de direcciones IP y físicas que ya conoce mediante dicho sistema.

Cuando una máquina se conecta a una red, envía un paquete ARP request con su dirección IP en el campo dirección IP destino (gratuitous ARP). Con dicho paquete indica al resto de máquinas de la red sus direcciones IP y físicas para que puedan añadirse a la tabla que ya tienen creada.Además, si alguna máquina comprueba que ambas tienen asignada la misma dirección IP, responderá a dicho paquete con la detección de duplicidad de direcciones IP dentro de la red.

El protocolo RARP es un protocolo de apoyo al nivel de red (Internet Layer) que efectúa la resolución de la dirección física a la dirección IP. Está definido en el RFC-903. La unidad de datos del protocolo a nivel RARP se denomina paquete RARP, que se encapsula en tramas del nivel de enlace (campo “Tipo de Trama” = 8035H). Existen dos tipos de paquetes RARP (Request y Reply).

Cuando una máquina que conoce su dirección física necesita conocer su dirección IP, difunde una trama que contiene un paquete RARP Request a todas las máquinas de su red (broadcast). Con este paquete se solicita al servidor RARP que tiene la tabla que relaciona direcciones físicas e IP, le corresponde a esa dirección física que respondan indicando su dirección IP.  Esto se da en los casos en los que dicha máquina no puede guardar su dirección IP, como máquinas sin unidades de disco, por lo que no pueden generar y guardar dichas tablas que relacionan direcciones físicas e IP de cada máquina de la red a la que pertenecen.

NEIGHBOR DISCOVERY

Neighbor Discovery (ND) es un protocolo de IPv6, y es equivalente al protocolo Address Resolution Protocol (ARP) en IPv4, aunque también incorpora las funcionalidades de otros protocolos de esta versión.

Consiste en un mecanismo con el cual un nodo que se acaba de incorporar a una red, descubre la presencia de otros nodos en el mismo enlace, además de ver sus direcciones IP. Este protocolo también se ocupa de mantener limpios los caches donde se almacena la información relativa al contexto de la red a la que está conectado un nodo. Así cuando una ruta hacia un cierto nodo falla el enrutador correspondiente buscara rutas alternativas. Emplea los mensajes de ICMPv6, y es la base para permitir el mecanismo de autoconfiguración en IPv6.

Tipos de paquetes

Solicitud de router: es generado por una interfaz cuando ésta es activada, para pedir a los nodos que se anuncien. Tipo en paquete ICMPv6 = 133.

Anunciación de router: producido por los nodos periódicamente (entre cada 4 y 1800 segundos), o bien se produce por una "solicitud de router", de esta manera informa de su presencia así como de otros parámetros de enlace y de Internet, como prefijos (uno o varios), tiempos de vida y configuración de direcciones. Es muy importante para permitir la remuneración. Tipo en paquete ICMPv6 = 134.

Solicitud de vecino: lo generan los nodos para determinar la dirección en la capa de enlace de sus vecinos, o para asegurarse de que el nodo vecino es alcanzable, aunque también se genera para detectar las direcciones IP duplicadas. Tipo en paquete ICMPv6 = 135.

Anunciación de vecino: los nodos lo producen como respuesta a la "solicitud de vecino", principalmente, aunque también para indicar cambios de direcciones en el nivel de enlace. Tipo en paquete ICMPv6 = 136.

Redirección: los nodos generan este paquete para informar a los enrutadores de que existe una ruta mejor para llegar a un determinado destino. Es equivalente, en parte a "ICMP redirect". Tipo en paquete ICMPv6 = 137.

Vecinos distantes ahora pueden estar conectados, debido a esta nueva característica que incorpora el nuevo protocolo.

OSPF (OPEN SHORTEST PATH FIRST, EL CAMINO MÁS CORTO PRIMERO)

OSPF se usa, como RIP, en la parte interna de las redes, su forma de funcionar es bastante sencilla. Cada router conoce los routers cercanos y las direcciones que posee cada router de los cercanos. Además de esto cada router sabe a qué distancia (medida en routers) está cada router. Así cuando tiene que enviar un paquete lo envía por la ruta por la que tenga que dar menos saltos.

Así por ejemplo un router que tenga tres conexiones a red, una a una red local en la que hay puesto de trabajo, otra (A) una red rápida frame relay de 48Mbps y una línea (B) RDSI de 64Kbps. Desde la red local va un paquete a W que esta por A a tres saltos y por B a dos saltos. El paquete iría por B sin tener en cuenta la saturación de la línea o el ancho de banda de la línea.

La O de OSPF viene de abierto, en este caso significa que los algoritmos que usa son de disposición pública.

L2TP

L2TP (Layer 2 Tunneling Protocol) fue diseñado por un grupo de trabajo de IETF como el heredero aparente de los protocolos PPTP y L2F, creado para corregir las deficiencias de estos protocolos y establecerse como un estándar aprobado por el IETF (RFC 2661). L2TP utiliza PPP para proporcionar acceso telefónico que puede ser dirigido a través de un túnel por Internet hasta un punto determinado. L2TP define su propio protocolo de establecimiento de túneles, basado en L2F. El transporte de L2TP está definido para una gran variedad de tipos de paquete de datos, incluyendo X.25, Frame Relay y ATM.

Al utilizar PPP para el establecimiento telefónico de enlaces, L2TP incluye los mecanismos de autenticación de PPP, PAP y CHAP. De forma similar a PPTP, soporta la utilización de estos protocolos de autenticación, como RADIUS.

A pesar de que L2TP ofrece un acceso económico, con soporte multiprotocolo y acceso a redes de área local remotas, no presenta unas características criptográficas especialmente robustas. Por ejemplo:

Sólo se realiza la operación de autenticación entre los puntos finales del túnel, pero no para cada uno de los paquetes que viajan por él. Esto puede dar lugar a suplantaciones de identidad en algún punto interior al túnel.

Sin comprobación de la integridad de cada paquete, sería posible realizar un ataque de denegación del servicio por medio de mensajes falsos de control que den por acabado el túnel L2TP o la conexión PPP subyacente.

L2TP no cifra en principio el tráfico de datos de usuario, lo cual puede dar problemas cuando sea importante mantener la confidencialidad de los datos.

A pesar de que la información contenida en los paquetes PiPP puede ser cifrada, este protocolo no dispone de mecanismos para generación automática de claves, o refresco automático de claves. Esto puede hacer que alguien que escuche en la red y descubra una única clave tenga acceso a todos los datos transmitidos.

A causa de estos inconvenientes, el grupo del IETF que trabaja en el desarrollo de PPP consideró la forma de solventarlos. Ante la opción de crear un nuevo conjunto de protocolos para L2TP del mismo estilo de los que se están realizando para IPSec, y dado la duplicación del trabajo respecto al propio grupo de desarrollo de IPSec que supondría, se tomó la decisión de utilizar los propios protocolos IPSec para proteger los datos que viajan por un túnel L2TP.

L2TP es en realidad una variación de un protocolo de encapsulamiento IP. Un túnel L2TP se crea encapsulando una trama L2TP en un paquete UDP, el cual es encapsulado a su vez en un paquete IP, cuyas direcciones de origen y destino definen los extremos del túnel. Siendo el protocolo de encapsulamiento más externo IP, los protocolos IPSec pueden ser utilizados sobre este paquete, protegiendo así la información que se transporta por el túnel.

POINT-TO-POINT PROTOCOL

Point-to-point Protocol (en español Protocolo punto a punto), también conocido por su acrónimo PPP Comúnmente usado para establecer una conexión directa entre dos nodos de red PPP es usado en varios tipos de redes físicas incluyendo, cable serial, línea telefónica, line troncal, telefonía celular, especializado en enlace de radio y enlace de fibra óptica como SONET. PPP también es usado en las conexiones de acceso a internet (mercadeado como “broadband”). Los Proveedores de Servicio de Internet (ISPs) han usado PPP para que accedan a internet los usuarios de dial-up, desde que los paquetes de IP no pueden ser transmitidos via modem, sin tener un protocolo de enlace de datos. Dos derivados del PPP son:

- Point to Point Protocolo over Ethernet (PPPoE)

- Point to Point Protocol over ATM (PPPoA)

Son usados comúnmente por Proveedores de Servició de Internet (ISPs) para establecer una Línea Subscriptora Digital (DSL) de servicios de internet para clientes. Por tanto, se trata de un protocolo asociado a la pila TCP/IP de uso en Internet.

El protocolo PPP permite establecer una comunicación a nivel de la capa de enlace TCP/IP entre dos computadoras. Generalmente, se utiliza para establecer la conexión a Internet de un particular con su proveedor de acceso a través de un módem telefónico. Ocasionalmente también es utilizado sobre conexiones de banda ancha (como PPPoE o PPPoA). Además del simple transporte de datos, PPP facilita dos funciones importantes:

Autenticación. Generalmente mediante una clave de acceso. Asignación dinámica de IP. Los proveedores de acceso cuentan con un

número limitado de direcciones IP y cuentan con más clientes que direcciones. Naturalmente, no todos los clientes se conectan al mismo tiempo. Así, es posible asignar una dirección IP a cada cliente en el momento en que se conectan al proveedor. La dirección IP se conserva hasta que termina la conexión por PPP. Posteriormente, puede ser asignada a otro cliente.

PPP también tiene otros usos, por ejemplo, se utiliza para establecer la comunicación entre un módem ADSL y la pasarela ATM del operador de telecomunicaciones.

También se ha venido utilizando para conectar a trabajadores desplazados (p. ej. ordenador portátil) con sus oficinas a través de un centro de acceso remoto de su empresa. Aunque está aplicación se está abandonando en favor de las redes privadas virtuales, más seguras.

CONTROL DE ACCESO AL MEDIO

En informática y telecomunicaciones, el control de acceso al medio es el conjunto de mecanismos y protocolos a través de los cuales varios "interlocutores" (dispositivos en una red, como ordenadores, teléfonos móviles, etc.) se ponen de acuerdo para compartir un medio de transmisión común (por lo general, un cable eléctrico u óptico o, en comunicaciones inalámbricas, el rango de frecuencias asignado a su sistema). No es el mismo concepto que la multiplexación aunque ésta es una técnica que pueden utilizar los mecanismos de control de acceso al medio.

Una analogía posible para el problema del acceso múltiple sería una habitación (que representaría el canal) en la que varias personas desean hablar al mismo tiempo. Si varias personas hablan a la vez, se producirán interferencias y se hará difícil la comprensión. Para evitar o reducir el problema, podrían hablar por turnos (estrategia de división por tiempo), hablar unos en tonos más agudos y otros más graves (división por frecuencia), dirigir sus voces en distintas direcciones de la habitación (división espacial) o hablar en idiomas distintos (división por código, como en CDMA); sólo las personas que conocen el código (es decir, el "idioma") pueden entenderlo

Algunas de las funciones de la subcapa MAC incluyen:

Controlar el acceso al medio físico de transmisión por parte de los dispositivos que comparten el mismo canal de comunicación.

Agregar la dirección MAC del nodo fuente y del nodo destino en cada una de las tramas que se transmiten.

Al transmitir en origen debe delimitar las tramas agregando bits de bandera (flags) para que el receptor pueda reconocer el inicio y fin de cada trama.

Al recibir en destino debe determinar el inicio y el final de una trama de datos dentro de una cadena de bits recibidos por la capa física.

Efectuar detección y, si procede, corrección de errores de transmisión. Descartar tramas duplicadas o erróneas

IPv4IPv4 es un protocolo orientado hacia datos que se utiliza para comunicación entre redes a través de interrupciones (switches) de paquetes (por ejemplo a través de Ethernet). Tiene las siguientes características:

• Es un protocolo de un servicio de datagramas no fiable (también referido como de mejor esfuerzo).

• No proporciona garantía en la entrega de datos.

• No proporciona ni garantías sobre la corrección de los datos.

• Puede resultar en paquetes duplicados o en desorden.

Todos los problemas mencionados se resuelven en el nivel superior en el modelo TCP/IP, por ejemplo, a través de TCP o UDP.

El propósito principal de IP es proveer una dirección única a cada sistema para asegurar que una computadora en Internet pueda identificar a otra.

DIRECCIONES

IPv4

IPv4 utiliza direcciones de 32 bits (4 bytes) que limita el número de direcciones posibles a utilizar a 4,294,967,295 direcciones únicas. Sin embargo, muchas de estas están reservadas para propósitos especiales como redes privadas, Multidifusión (Multicast), etc. Debido a esto se reduce el número de direcciones IP que realmente se pueden utilizar, es esto mismo lo que ha impulsado la creación de IPv6 (actualmente en desarrollo) como reemplazo eventual dentro de algunos años para IPv4.

Representación de las direcciones.

Cuando se escribe una dirección IPv4 en cadenas, la notación más común es la decimal con puntos. Hay otras notaciones basadas sobre los valores de los octetos de la dirección IP.

Utilizando como ejemplo: www.alcancelibre.org que tiene como dirección IP 201.161.1.226 en la notación decimal con puntos:

Notación Valor Conversión desde decimal con puntos

Decimal con puntos

201.161.1.226 -

Hexadecimal con puntos

0xC9.0xA1.0x01.0xE2 Cada octeto de la dirección es convertido individualmente a hexadecimal.

Octal con 0311.0241.0001.0342 Cada octeto es

Notación Valor Conversión desde decimal con puntos

puntos convertido individualmente a octal.

Binario con puntos

11001001.10100001.00000001.11100010

Cada octeto es convertido individualmente a binario

Hexadecimal 0xC9A101E2 Concatenación de los octetos de hexadecimal con puntos.

Decimal 3382772194 La forma hexadecimal convertida a decimal.

Octal 31150200742 La forma hexadecimal convertida a octal.

Binario 11001001101000010000000111100010 La forma hexadecimal convertida a binario.

Teóricamente, todos estos formatos mencionados deberían ser reconocidos por los navegadores (sin combinar). Además, en las formas con puntos, cada octeto puede ser representado en combinación de diferentes bases. Ejemplo: 201.0241.0x01.226.

Transfiere direcciones de protocolos de 32 bits. Sostiene aproximadamente 4,29 billones de IPs alrededor del mundo, provocando la crisis actual que ocasiona que el sistema ya no soporte más direcciones.

Problemas IPv4 demostró por su duración un diseño flexible y poderoso, pero está

empezando a tener problemas, en especial por el crecimiento en poco tiempo de la necesidad de direcciones IP. Bagnulo señaló que ya se asignó el 60 por ciento de las direcciones IP disponibles en IPv4, y que sólo queda un 25 por ciento para utilizar. El 15 por ciento se reserva para usos técnicos

IPv6

IPv6 es una extensión conservadora de IPv4. La mayoría de los protocolos de transporte -y aplicación- necesitan pocos o ningún cambio para operar sobre IPv6; las excepciones son los protocolos de aplicación que integran direcciones de capa de red, como FTP o NTPv3, NTPv4.

IPv6 especifica un nuevo formato de paquete, diseñado para minimizar el procesamiento del encabezado de paquetes. Debido a que las cabeceras de los paquetes IPv4 e IPv6 son significativamente distintas, los dos protocolos no son interoperables.

Direccionamiento IPv6

Artículo principal: Dirección IPv6.

El cambio más grande de IPv4 a IPv6 es la longitud de las direcciones de red. Las direcciones IPv6, definidas en el RFC 2373 y RFC 2374 pero fue redefinida en abril de 2003 en la RFC 3513, son de 128 bits; esto corresponde a 32 dígitos hexadecimales, que se utilizan normalmente para escribir las direcciones IPv6, como se describe en la siguiente sección.

El número de direcciones IPv6 posibles es de 2128 ≈ 3.4 x 1038. Este número puede también representarse como 1632, con 32 dígitos hexadecimales, cada uno de los cuales puede tomar 16 valores (véase combinatoria).

En muchas ocasiones las direcciones IPv6 están compuestas por dos partes lógicas: un prefijo de 64 bits y otra parte de 64 bits que corresponde al identificador de interfaz, que casi siempre se genera automáticamente a partir de la dirección MAC de la interfaz a la que está asignada la dirección.

Notación para las direcciones IPv6

Las direcciones IPv6, de 128 bits de longitud, se escriben como ocho grupos de cuatro dígitos hexadecimales. Por ejemplo,

2001:0db8:85a3:08d3:1319:8a2e:0370:7334

Es una dirección IPv6 válida.

Se puede comprimir un grupo de cuatro dígitos si éste es nulo (es decir, toma el valor "0000"). Por ejemplo,

2001:0db8:85a3:0000:1319:8a2e:0370:7344 ---- 2001:0db8:85a3::1319:8a2e:0370:7344

Siguiendo esta regla, si más de dos grupos consecutivos son nulos, también pueden comprimirse como "::". Si la dirección tiene más de una serie de grupos nulos consecutivos la compresión sólo se permite en uno de ellos. Así, las siguientes son representaciones posibles de una misma dirección:

2001:0DB8:0000:0000:0000:0000:1428:57ab2001:0DB8:0000:0000:0000::1428:57ab2001:0DB8:0:0:0:0:1428:57ab2001:0DB8:0::0:1428:57ab2001:0DB8::1428:57ab

Son todas válidas y significan lo mismo, pero

2001::25de::cade -- --

No es válida porque no queda claro cuántos grupos nulos hay en cada lado.

Los ceros iniciales en un grupo también se pueden omitir:

2001:0DB8:02de::0e132001:DB8:2de::e13

Si la dirección es una dirección IPv4 empotrada, los últimos 32 bits pueden escribirse en base decimal, así:

::ffff:192.168.89.9::ffff:c0a8:5909

No se debe confundir con:

::192.168.89.9::c0a8:5909

El formato ::ffff:1.2.3.4 se denomina dirección IPv4 mapeada, y el formato ::1.2.3.4 dirección IPv4 compatible.

Las direcciones IPv4 pueden ser transformadas fácilmente al formato IPv6. Por ejemplo, si la dirección decimal IPv4 es 135.75.43.52 (en hexadecimal, 0x874B2B34), puede ser convertida a 0000:0000:0000:0000:0000:0000:874B:2B34 o ::874B:2B34. Entonces, uno puede usar la notación mixta dirección IPv4 compatible, en cuyo caso la dirección debería ser ::135.75.43.52. Este tipo de dirección IPv4 compatible casi no está siendo utilizada en la práctica, aunque los estándares no la han declarado obsoleta.

Cuando lo que se desea es identificar un rango de direcciones diferenciable por medio de los primeros bits, se añade este número de bits tras el carácter de barra "/". Por ejemplo:

2001:0DB8::1428:57AB/96 sería equivalente a 2001:0DB8::2001:0DB8::874B:2B34/96 sería equivalente a 2001:0DB8:: y por supuesto también a 2001:0DB8::1428:57AB/96

IDENTIFICACIÓN DE LOS TIPOS DE DIRECCIONES

Los tipos de direcciones IPv6 pueden identificarse tomando en cuenta los rangos definidos por los primeros bits de cada dirección.

::/128

La dirección con todo ceros se utiliza para indicar la ausencia de dirección, y no se asigna ningún nodo.

::1/127

La dirección de loopback es una dirección que puede usar un nodo para enviarse paquetes a sí mismo (corresponde con 127.0.0.1 de IPv4). No puede asignarse a ninguna interfaz física.

::1.2.3.4/96

La dirección IPv4 compatible se usa como un mecanismo de transición en las redes duales IPv4/IPv6. Es un mecanismo que no se usa.

::ffff:0:0/96

La dirección IPv4 mapeada se usa como mecanismo de transición en terminales duales.

fe80::/10

El prefijo de enlace local (en inglés link local) específica que la dirección sólo es válida en el enlace físico local.

fec0::

El prefijo de emplazamiento local (en inglés site-local prefix) específica que la dirección sólo es válida dentro de una organización local. La RFC 3879 lo declaró obsoleto, estableciendo que los sistemas futuros no deben implementar ningún soporte para este tipo de dirección especial. Se deben sustituir por direcciones Local IPv6 Unicast.

ff00::/8

El prefijo de multicast. Se usa para las direcciones multicast.

Hay que resaltar que no existen las direcciones de difusión (en inglés broadcast) en IPv6, aunque la funcionalidad que prestan puede emularse utilizando la dirección multicast FF01::1/128, denominada todos los nodos (en inglés all nodes)

Paquete IPv6

Un paquete en IPv6 está compuesto principalmente de dos partes: la cabecera (que tiene una parte fija y otra con las opciones) y la carga útil (los datos).

Cabecera fija

Los primeros 40 bytes (320 bits) son la cabecera del paquete y contiene los siguientes campos:

Offset del Octet

0 1 2 3

o

Bit Offset

0 1 2 3 45678910

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

0 0 Versión

Clase de Tráfico

Etiqueta de Flujo

4 32 Longitud del campo de datos Cabecera Siguiente Límite de Saltos

8 64

Dirección de OrigenC 96

10 128

14 160

18 192

Dirección de Destino1C 224

20 256

24 288

direcciones de origen (128 bits) direcciones de destino (128 bits) versión del protocolo IP (4 bits) clase de tráfico (8 bits, Prioridad del Paquete) Etiqueta de flujo (20 bits, manejo de la Calidad de Servicio), Longitud del campo de datos (16 bits) Cabecera siguiente (8 bits) Límite de saltos (8 bits, Tiempo de Vida).

Hay dos versiones de IPv6 levemente diferentes. La ahora obsoleta versión inicial, descrita en el RFC 1883, difiere de la actual versión propuesta de estándar, descrita en el RFC 2460, en dos campos: hay 4 bits que han sido reasignados desde "etiqueta de flujo" (flow label) a "clase de tráfico" (traffic class). El resto de diferencias son menores.

En IPv6 la fragmentación se realiza sólo en el nodo origen del paquete, al contrario que en IPv4 en donde los routers pueden fragmentar un paquete. En

IPv6, las opciones también desaparecen de la cabecera estándar y son especificadas por el campo "Cabecera Siguiente" (Next Header), similar en funcionalidad en IPv4 al campo Protocolo. Un ejemplo: en IPv4 uno añadiría la opción "ruta fijada desde origen" (Strict Source and Record Routing) a la cabecera IPv4 si quiere forzar una cierta ruta para el paquete, pero en IPv6 uno modificaría el campo "Cabecera Siguiente" indicando que viene una cabecera de encaminamiento. La cabecera de encaminamiento podrá entonces especificar la información adicional de encaminamiento para el paquete, e indicar que, por ejemplo, la cabecera TCP será la siguiente. Este procedimiento es análogo al de AH y ESP en IPsec para IPv4 (que aplica a IPv6 de igual modo, por supuesto).

Cabeceras de extensión

El uso de un formato flexible de cabeceras de extensión opcionales es una idea innovadora que permite ir añadiendo funcionalidades de forma paulatina. Este diseño aporta gran eficacia y flexibilidad ya que se pueden definir en cualquier momento a medida que se vayan necesitando entre la cabecera fija y la carga útil.

Hasta el momento, existen 8 tipos de cabeceras de extensión, donde la cabecera fija y las de extensión opcionales incluyen el campo de cabecera siguiente que identifica el tipo de cabeceras de extensión que viene a continuación o el identificador del protocolo de nivel superior. Luego las cabeceras de extensión se van encadenando utilizando el campo de cabecera siguiente que aparece tanto en la cabecera fija como en cada una de las citadas cabeceras de extensión. Como resultado de la secuencia anterior, dichas cabeceras de extensión se tienen que procesar en el mismo orden en el que aparecen en el datagrama. La Cabecera principal, tiene a diferencia de la cabecera de la versión IPv4 un tamaño fijo de 40 octetos. Específica para asignarlos para aplicaciones multicast intra-dominio o entre-dominios (RFC 3306). En IPv4 era muy difícil para una organización como ésta.

Todas o parte de estas cabeceras de extensión tienen que ubicarse en el datagrama en el orden especificado:

Cabecera de Extensión

Tipo Tamaño Descripción RFC

Opciones salto a salto (Hop-By-Hop Options)

0 variable Contiene datos que deben ser examinados por cada

RFC 2460

nodo a través de la ruta de envío de un paquete.

Ruteo (Routing) 43 variable Métodos para especificar la forma de rutear un datagrama. (Usado con IPv6 móvil)

RFC 2460, RFC 6275, RFC 5095

Cabecera de fragmentación (Fragment)

44 64 bits Contiene parámetros para la fragmentación de los datagramas.

RFC 2460

Cabecera de autenticación (Authentication Header (AH))

51 variable Contiene información para verificar la autenticación de la mayor parte de los datos del paquete (Ver IPsec)

RFC 4302

Encapsulado de seguridad de la carga útil (Encapsulating Security Payload (ESP))

50 variable Lleva la información cifrada para comunicación segura (Ver IPsec).

RFC 4303

Opciones para el destino (Destination Options)

60 variable Información que necesita ser examinada solamente por los nodos de destino del paquete.

RFC 2460

No Next Header 59 vacío Indica que no hay más cabeceras

RFC 2460

Cada cabecera de extensión debe aparecer como mucho una sola vez, salvo la cabecera de opción destino, que puede aparecer como mucho dos veces, una antes de la cabecera ruteo y otra antes de la cabecera de la capa superior.

Carga útil

La carga útil del paquete puede tener un tamaño de hasta 64 KB en modo estándar, o mayor con una opción de carga jumbo (jumbo payload) en el encabezado opcional Hop-By-Hop.

La fragmentación es manejada solamente en el host que envía la información en IPv6: los routers nunca fragmentan un paquete y los hosts se espera que utilicen el Path MTU discovery.

IPV6 Y EL SISTEMA DE NOMBRES DE DOMINIO

Las direcciones IPv6 se representan en el sistema de nombres de dominio (DNS) mediante registros AAAA (también llamados registros de quad-A, por tener una longitud cuatro veces la de los registros A para IPv4)

El concepto de AAAA fue una de las dos propuestas al tiempo que se estaba diseñando la arquitectura IPv6. La otra propuesta utilizaba registros A6 y otras innovaciones como las etiquetas de cadena de bits (bit-string labels) y los registros DNAME.

Mientras que la idea de AAAA es una simple generalización del DNS IPv4, la idea de A6 fue una revisión y puesta a punto del DNS para ser más genérico, y de ahí su complejidad.

La RFC 3363 recomienda utilizar registros AAAA hasta tanto se pruebe y estudie exhaustivamente el uso de registros A6. La RFC 3364 realiza una comparación de las ventajas y desventajas de cada tipo de registro.

Procesamiento simplificado en los routers

Se hicieron varias simplificaciones en la cabecera de los paquetes, así como en el proceso de reenvío de paquetes para hacer el procesamiento de los paquetes más simple y por ello más eficiente. En concreto,

El encabezado del paquete en IPv6 es más simple que el utilizado en IPv4, así los campos que son raramente utilizados han sido movidos a opciones separadas; en efecto, aunque las direcciones en IPv6 son 4 veces más largas, el encabezado IPv6 (sin opciones) es solamente el doble de largo que el encabezado IPv4 (sin opciones).

Los routers IPv6 no hacen fragmentación. Los nodos IPv6 requieren ya sea hacer descubrimiento de MTU, realizar fragmentación extremo a extremo o enviar paquetes menores al MTU mínimo de IPv6 de 1280 bytes.

El encabezado IPv6 no está protegido por una suma de comprobación (checksum); la protección de integridad se asume asegurada tanto por el checksum de capa de enlace y por un checksum de nivel superior (TCP, UDP, etc.). En efecto, los routers IPv6 no necesitan recalcular la suma de comprobación cada vez que algún campo del encabezado (como el contador de saltos o Tiempo de Vida) cambian. Esta mejora puede ser menos necesaria en routers que utilizan hardware dedicado para computar este cálculo y así pueden hacerlo a velocidad de línea (wirespeed), pero es relevante para routers por software.

El campo Tiempo de Vida de IPv4, conocido como TTL (Time To Live), pasa a llamarse Límite de saltos, reflejando el hecho de que ya no se espera que los routers computen el tiempo en segundos que tarda en atravesarlo (que en cualquier caso siempre resulta menor de 1 segundo).

Se simplifica como el número de saltos entre routers que se permita realizar al paquete IPv6.

ICMP

El Protocolo de Mensajes de Control de Internet o ICMP (por sus siglas en inglés de Internet Control Message Protocol) es el sub protocolo de control y notificación de errores del Protocolo de Internet (IP). Como tal, se usa para enviar mensajes de error, indicando por ejemplo que un servicio determinado no está disponible o que un router o host no puede ser localizado. También puede ser utilizado para transmitir mensajes ICMP Query.

Este protocolo es parte de la suite de protocolo de Internet, de esta manera se define en RFC 792. Los mensajes de este protocolo se utilizan con fines de diagnóstico o control y se generan en respuesta a los errores en IP operaciones (como se especifica en el RFC 1122). Estos errores del protocolo ICMP se dirigen a la dirección IP de origen del paquete originario.

Podríamos decir, que todos los dispositivos (como intermedio enrutador) reenvían un datagrama IP que disminuye el tiempo de vida en el encabezado IP por uno. Si el tiempo de vida (TTL) resultante es 0, el paquete se descartara y un ICMP de tiempo de vida superado en tránsito enviara un mensaje de dirección al origen del datagrama.

ICMPv6

Protocolo de Mensajes de Control de Internet Version 6 (ICMPv6 o ICMP para IPv6) es una nueva versión de ICMP y es una parte importante de la arquitectura IPv6 que debe estar completamente soportada por todas las implementaciones y nodos IPv6. ICMPv6 combina funciones que anteriormente estaban subdivididas en varias partes de diferentes protocolos tales como ICMP, IGMP o ARP y además introduce algunas simplificaciones eliminando tipos de mensajes obsoletos que estaban en desuso actualmente.

PROTOCOLO DE RED IGMP

El protocolo de red IGMP se utiliza para intercambiar información acerca del estado de pertenencia entre enrutadores IP que admiten la multidifusión y miembros de grupos de multidifusión. Los hosts miembros individuales informan

acerca de la pertenencia de hosts al grupo de multidifusión y los enrutadores de multidifusión sondean periódicamente el estado de la pertenencia.

Tipo

Hay cuatro tipos establecidos, y se detallan a continuación:

-Consulta de asociación: enviada por un encaminador de multidifusión. Hay dos subtipos: una consulta general, utilizada para aprender qué grupos tienen miembros en una red conectada; y una consulta específica de grupo, utilizada para aprender si un grupo particular tiene algún miembro en una red conectada.

-Informes de asociación: enviado por un host para declarar sus miembros asociados a un grupo.

-Abandono de grupo: enviado por un host para declarar que abandona el grupo.

-Tiempo máximo de respuesta: Solamente significativo en un mensaje de consulta de asociación, y especifica el máximo tiempo permitido antes de enviar un informe de respuesta en unidades de 1/10 segundos.

Suma de comprobación

Un código de detección de errores, calculado como el complemento a 1 de 16 bits más cuatro palabras de 16 bits del mensaje. Para propósitos de computación, el campo "Suma de Comprobación" se inicia a valor 0.

Dirección de grupo

Cero en un mensaje de respuesta, y una dirección de grupo multidifusión IP válida en un informe de asociación o en un mensaje de abandono.

TRANSMISSION CONTROL PROTOCOL

Transmission Control Protocol (en español Protocolo de Control de Transmisión) o TCP, es uno de los protocolos fundamentales en Internet. Fue creado entre los años 1973 y 1974 por Vint Cerf y Robert Kahn.

Muchos programas dentro de una red de datos compuesta por computadoras, pueden usar TCP para crear conexiones entre ellos a través de las cuales puede enviarse un flujo de datos. El protocolo garantiza que los datos serán entregados en su destino sin errores y en el mismo orden en que se transmitieron. También proporciona un mecanismo para distinguir distintas aplicaciones dentro de una misma máquina, a través del concepto de puerto.

TCP da soporte a muchas de las aplicaciones más populares de Internet (navegadores, intercambio de ficheros, clientes FTP, etc.) y protocolos de aplicación HTTP, SMTP, SSH y FTP.

Funciones de TCP

En la pila de protocolos TCP/IP, TCP es la capa intermedia entre el protocolo de internet (IP) y la aplicación. Habitualmente, las aplicaciones necesitan que la comunicación sea fiable y, dado que la capa IP aporta un servicio de datagramas no fiable (sin confirmación), TCP añade las funciones necesarias para prestar un servicio que permita que la comunicación entre dos sistemas se efectúe libre de errores, sin pérdidas y con seguridad.

Las conexiones TCP se componen de tres etapas: establecimiento de conexión, transferencia de datos y fin de la conexión. Para establecer la conexión se usa el procedimiento llamado negociación en tres pasos (3-way handshake). Para la desconexión se usa una negociación en cuatro pasos (4-way handshake). Durante el establecimiento de la conexión, se configuran algunos parámetros tales como el número de secuencia con el fin de asegurar la entrega ordenada de los datos y la robustez de la comunicación.

Puertos TCP

TCP usa el concepto de número de puerto para identificar a las aplicaciones emisoras y receptoras. Cada lado de la conexión TCP tiene asociado un número de puerto (de 16 bits sin signo, con lo que existen 65536 puertos posibles) asignado por la aplicación emisora o receptora. Los puertos son clasificados en tres categorías: bien conocidos, registrados y dinámicos/privados. Los puertos bien conocidos son asignados por la Internet Assigned Numbers Authority (IANA), van del 0 al 1023 y son usados normalmente por el sistema o por procesos con privilegios. Las aplicaciones que usan este tipo de puertos son ejecutadas como servidores y se quedan a la escucha de conexiones. Algunos ejemplos son: FTP (21), SSH (22), Telnet (23), SMTP (25) y HTTP (80).

Los puertos registrados son normalmente empleados por las aplicaciones de usuario de forma temporal cuando conectan con los servidores, pero también pueden representar servicios que hayan sido registrados por un tercero (rango de puertos registrados: 1024 al 49151). Los puertos dinámicos/privados también pueden ser usados por las aplicaciones de usuario, pero este caso es menos común. Los puertos dinámicos/privados no tienen significado fuera de la conexión TCP en la que fueron usados (rango de puertos dinámicos/privados: 49152 al 65535, recordemos que el rango total de 2 elevado a la potencia 16, cubre 65536 números, del 0 al 65535)

Transferencia de datos

Durante la etapa de transferencia de datos, una serie de mecanismos claves determinan la fiabilidad y robustez del protocolo. Entre ellos están incluidos el uso del número de secuencia para ordenar los segmentos TCP recibidos y detectar paquetes duplicados, checksums para detectar errores, y asentimientos y temporizadores para detectar pérdidas y retrasos.

Durante el establecimiento de conexión TCP, los números iniciales de secuencia son intercambiados entre las dos entidades TCP. Estos números de secuencia son usados para identificar los datos dentro del flujo de bytes, y poder identificar (y contar) los bytes de los datos de la aplicación. Siempre hay un par de números de secuencia incluidos en todo segmento TCP, referidos al número de secuencia y al número de asentimiento. Un emisor TCP se refiere a su propio número de secuencia cuando habla de número de secuencia, mientras que con el número de asentimiento se refiere al número de secuencia del receptor. Para mantener la fiabilidad, un receptor asiente los segmentos TCP indicando que ha recibido una parte del flujo continuo de bytes. Una mejora de TCP, llamada asentimiento selectivo (SACK, Selective Acknowledgement) permite a un receptor TCP asentir los datos que se han recibido de tal forma que el remitente solo retransmita los segmentos de datos que faltan.

USER DATAGRAM PROTOCOL (UDP)

User Datagram Protocol (UDP) es un protocolo del nivel de transporte basado en el intercambio de datagramas (Encapsulado de capa 4 Modelo OSI). Permite el envío de datagramas a través de la red sin que se haya establecido previamente una conexión, ya que el propio datagrama incorpora suficiente información de direccionamiento en su cabecera. Tampoco tiene confirmación ni control de flujo, por lo que los paquetes pueden adelantarse unos a otros; y tampoco se sabe si ha

llegado correctamente, ya que no hay confirmación de entrega o recepción. Su uso principal es para protocolos como DHCP, BOOTP, DNS y demás protocolos en los que el intercambio de paquetes de la conexión/desconexión son mayores, o no son rentables con respecto a la información transmitida, así como para la transmisión de audio y vídeo en tiempo real, donde no es posible realizar retransmisiones por los estrictos requisitos de retardo que se tiene en estos casos.

UDP utiliza puertos para permitir la comunicación entre aplicaciones. El campo de puerto tiene una longitud de 16 bits, por lo que el rango de valores válidos va de 0 a 65.535. El puerto 0 está reservado, pero es un valor permitido como puerto origen si el proceso emisor no espera recibir mensajes como respuesta.

Los puertos 1 a 1023 se llaman puertos "bien conocidos" y en sistemas operativos tipo Unix enlazar con uno de estos puertos requiere acceso como superusuario.

Los puertos 1024 a 49.151 son puertos registrados.

Los puertos 49.152 a 65.535 son puertos efímeros y son utilizados como puertos temporales, sobre todo por los clientes al comunicarse con los servidores.

COMPARATIVA ENTRE UDP Y TCP (TRANSMISSION CONTROL PROTOCOL)

UDP: proporciona un nivel de transporte no fiable de datagramas, ya que apenas añade la información necesaria para la comunicación extremo a extremo al paquete que envía al nivel inferior. Lo utilizan aplicaciones como NFS (Network File System) y RCP (comando para copiar ficheros entre ordenadores remotos), pero sobre todo se emplea en tareas de control y en la transmisión de audio y vídeo a través de una red. No introduce retardos para establecer una conexión, no mantiene estado de conexión alguno y no realiza seguimiento de estos parámetros. Así, un servidor dedicado a una aplicación particular puede soportar más clientes activos cuando la aplicación corre sobre UDP en lugar de sobre TCP.

TCP: es el protocolo que proporciona un transporte fiable de flujo de bits entre aplicaciones. Está pensado para poder enviar grandes cantidades de información de forma fiable, liberando al programador de la dificultad de gestionar la fiabilidad de la conexión (retransmisiones, pérdida de paquetes, orden en el que llegan los paquetes, duplicados de paquetes...) que gestiona el propio protocolo. Pero la complejidad de la gestión de la fiabilidad tiene un coste en eficiencia, ya que para llevar a cabo las gestiones anteriores se tiene que añadir bastante información a los paquetes que enviar. Debido a que los paquetes para enviar tienen un

tamaño máximo, cuanta más información añada el protocolo para su gestión, menos información que proviene de la aplicación podrá contener ese paquete (el segmento TCP tiene una sobrecarga de 20 bytes en cada segmento, mientras que UDP solo añade 8 bytes). Por eso, cuando es más importante la velocidad que la fiabilidad, se utiliza UDP. En cambio, TCP asegura la recepción en destino de la información para transmitir.

DATAGRAM CONGESTION CONTROL PROTOCOL (DCCP) O PROTOCOLO DE CONTROL DE CONGESTIÓN DE DATAGRAMAS

Datagram Congestion Control Protocol (DCCP) o Protocolo de Control de Congestión de Datagramas es un protocolo de nivel de transporte orientado al mensaje.

Entre las aplicaciones que querrían implementar el DCCP se incluyen aquellas que tienen necesidad de entrega rápida de datos, y que combinada con la implementación de algún método de control de congestión, resulta generalmente en el arribo extemporáneo de la información, convirtiéndose en inútil. Esta categoría de aplicaciones incluye la telefonía en Internet y multimedia en tiempo real, entre otras.

El control de congestión es la forma en que el protocolo de red descubre la capacidad disponible de la red para una ruta en particular. La motivación original para el desarrollo del DCCP es proveer a este tipo de aplicaciones una vía para acceder a los mecanismos estándar de control de congestión sin tener que implementarlos en el nivel de aplicación.

STREAM CONTROL TRANSMISSION PROTOCOL (SCTP)

Stream Control Transmission Protocol (SCTP) es un protocolo de comunicación de capa de transporte que fue definido por el grupo SIGTRAN de IETF en el año 2000. El protocolo está especificado en la RFC 2960, y la RFC 3286 brinda una introducción al mismo.

SCTP es una alternativa a los protocolos de transporte TCP y UDP pues provee confiabilidad, control de flujo y secuenciación como TCP. Sin embargo, SCTP opcionalmente permite el envío de mensajes fuera de orden y a diferencia de TCP, SCTP es un protocolo orientado al mensaje (similar al envío de datagramas UDP).

Las ventajas de SCTP son:

Capacidad de Multihoming, en la cual uno (o dos) de los extremos de una asociación (conexión) pueden tener más de una dirección IP. Esto permite reaccionar en forma transparente ante fallos en la red.

Entrega de los datos en trozos que forman parte de flujos independientes y paralelos —eliminando así el problema de head of the line blocking que sufre TCP.

Es capaz de seleccionar y monitorizar caminos, seleccionando un camino "primario" y verificando constantemente la conectividad de cada uno de los caminos alternativos.

Mecanismos de validación y asentimiento como protección ante ataques por inundación, proveyendo notificación de trozos de datos duplicados o perdidos.

SCTP fue diseñado inicialmente por el grupo Sigtran para transportar señalización telefónica SS7 sobre IP. La intención fue la de proveer en IP de algunas de las características de confiabilidad de SS7. Por su versatilidad luego se ha propuesto utilizarlo en otras áreas, como por ejemplo para transportar mensajes de los protocolos DIAMETER o SIP.

EL PROTOCOLO DE RESERVA DE RECURSOS (RSVP O RESOURCE RESERVATION PROTOCOL)

El protocolo de reserva de recursos (RSVP o Resource Reservation Protocol), descrito en RFC 2205, es un protocolo de la capa de transporte diseñado para reservar recursos de una red bajo la arquitectura de servicios integrados (IntServ). "RSVP no es una aplicación de transporte, es más bien un protocolo de control de internet, como ICMP, IGMP, o protocolos de enrutamiento" - RFC 2205. RSVP reserva los canales o rutas en redes internet para la transmisión por unidifusión y multidifusión con escalabilidad y robustez.

RSVP puede ser utilizado tanto por hosts como por routers para pedir o entregar niveles específicos de calidad de servicio (QoS) para los flujos de datos de las aplicaciones. RSVP define cómo deben hacer las reservas las aplicaciones y cómo liberar los recursos reservados una vez que han terminado. Las operaciones RSVP generalmente dan como resultado una reserva de recursos en cada nodo a lo largo de un camino.

RSVP no es en sí mismo un protocolo de encaminamiento y fue diseñado para interoperar con los actuales y futuros protocolos de encaminamiento.

A continuación se describen los atributos principales del protocolo:

1. RSVP pide recursos para los flujos simplex: un flujo de tráfico en una sola dirección desde el emisor a uno o más receptores.

2. RSVP no es un protocolo de encaminamiento, pero trabaja con protocolos de enrutamiento actuales y futuros.

3. RSVP está orientada hacia el receptor: es el receptor de un flujo de datos el que inicia y mantiene la reserva de recursos para ese flujo.

4. RSVP es soft state (la reserva en cada nodo necesita refresco periódico), mantiene solo temporalmente es estado de las reservas de recursos del host y de los routers, de aquí que soporte cambios dinámicos de la red.

5. RSVP proporciona varios estilos de reserva (un conjunto de opciones) y permite que se añadan futuros estilos al protocolo para permitirle adaptarse a diversas aplicaciones.

6. RSVP transporta y mantiene parámetros del tráfico y de la política de control que son opacos a RSVP.

DHCP

DHCP (sigla en inglés de Dynamic Host Configuration Protocol, en español «protocolo de configuración dinámica de host») es un protocolo de red que permite a los clientes de una red IP obtener sus parámetros de configuración automáticamente. Se trata de un protocolo de tipo cliente/servidor en el que generalmente un servidor posee una lista de direcciones IP dinámicas y las va asignando a los clientes conforme éstas van estando libres, sabiendo en todo momento quién ha estado en posesión de esa IP, cuánto tiempo la ha tenido y a quién se la ha asignado después.

Implementaciones

Microsoft introdujo el DHCP en sus Servidores NT con la versión 3.5 de Windows NT a finales de 1994.

El Consorcio de Software de Internet (ISC: Internet Software Consortium) publicó distribuciones de DHCP para Unix con la versión 1.0.0 del ISC DHCP Server el 6 de diciembre de 1997 y una versión (2.0) que se adaptaba mejor al RFC el día 22 de junio de 1999. Se puede encontrar el software en http://www.isc.org/sw/dhcp/

Otras implementaciones importantes incluyen:

Cisco: un servidor DHCP habilitado en Cisco IOS 12.0 en el mes de febrero de 1999

Sun: añadió el soporte para DHCP a su sistema operativo Solaris el 8 de julio de 2001.

Además, varios routers incluyen soporte DHCP para redes de hasta 255 dispositivos.

DHCPv6

DHCPv6 es el Protocolo de Configuración Dinámica de Hosts para IPv6.

Aunque IPv6 resuelve la auto configuración de direcciones, lo cual es la principal motivación de DHCP en IPv4. DHCPv6 aún tiene sentido, ya que le brinda más control al administrador de la red sobre las asignaciones.

Esta configuración permite un mayor control de la asignación de direcciones, así como mayor amplitud en la configuración de servicios de red. Usar el protocolo DHCPv6 definido a través del “RFC 3315: Dynamic host configuration protocol for IPv6 (DHCPv6)” y “RFC 4361: Node-specific client identifiers for DHCP”.

DHCPv6 puede trabajar de forma conjunta y con el mecanismo “stateless”. El administrador de red determina que procesos se van a emplear a través de los mensajes “RA” de ICMPv6. También permite a los clientes la solicitud de múltiples direcciones IPv6, que no era posible en IPv4 ni a través del mecanismo “stateless”.

En este caso, es necesaria la existencia de un servidor, que puede entregar además de la dirección de red, parámetros adicionales. El servidor mantiene una base de datos con las direcciones asignadas y los hosts que fueron asignados, por ello el nombre de “statefull”, ya que se dispone de un mantenimiento del estado de asignación.

DOMAIN NAME SYSTEM O DNS

Domain Name System o DNS (en español: sistema de nombres de dominio) es un sistema de nomenclatura jerárquica para computadoras, servicios o cualquier recurso conectado a Internet o a una red privada. Este sistema asocia información variada con nombres de dominios asignado a cada uno de los participantes. Su función más importante, es traducir (resolver) nombres inteligibles para las personas en identificadores binarios asociados con los equipos conectados a la red, esto con el propósito de poder localizar y direccionar estos equipos mundialmente.

El servidor DNS utiliza una base de datos distribuida y jerárquica que almacena información asociada a nombres de dominio en redes como Internet. Aunque como base de datos el DNS es capaz de asociar diferentes tipos de información a cada nombre, los usos más comunes son la asignación de nombres de dominio a direcciones IP y la localización de los servidores de correo electrónico de cada dominio.

El protocolo FTP (Protocolo de transferencia de archivos) es, como su nombre lo indica, un protocolo para transferir archivos.

La implementación del FTP se remonta a 1971 cuando se desarrolló un sistema de transferencia de archivos (descrito en RFC141) entre equipos del Instituto Tecnológico de Massachusetts (MIT, Massachusetts Institute of Technology). Desde entonces, diversos documentos de RFC (petición de comentarios) han mejorado el protocolo básico, pero las innovaciones más importantes se llevaron a cabo en julio de 1973.

Actualmente, el protocolo FTP está definido por RFC 959 (Protocolo de transferencia de archivos (FTP) - Especificaciones).

LA FUNCIÓN DEL PROTOCOLO FTP

El protocolo FTP define la manera en que los datos deben ser transferidos a través de una red TCP/IP.

El objetivo del protocolo FTP es:

permitir que equipos remotos puedan compartir archivos permitir la independencia entre los sistemas de archivo del equipo del

cliente y del equipo del servidor permitir una transferencia de datos eficaz

HTTP

Hypertext Transfer Protocol o HTTP (en español protocolo de transferencia de hipertexto) es el protocolo usado en cada transacción de la World Wide Web. HTTP fue desarrollado por el World Wide Web Consortium y la Internet Engineering Task Force, colaboración que culminó en 1999 Es un protocolo orientado a transacciones y sigue el esquema petición-respuesta entre un cliente y un servidor. Al cliente que efectúa la petición (un navegador web o un spider) se lo conoce como "user agent" (agente del usuario). A la información transmitida se la llama recurso y se la identifica mediante un localizador uniforme de recursos (URL). Los recursos pueden ser archivos, el resultado de la ejecución de un programa, una consulta a una base de datos, la traducción automática de un documento, etc.

HTTP es un protocolo sin estado, es decir, que no guarda ninguna información sobre conexiones anteriores. El desarrollo de aplicaciones web necesita frecuentemente mantener estado. Para esto se usan las cookies, que es información que un servidor puede almacenar en el sistema cliente. Esto le permite a las aplicaciones web instituir la noción de "sesión", y también permite rastrear usuarios ya que las cookies pueden guardarse en el cliente por tiempo indeterminado.

IMAP

Internet Message Access Protocol, o su acrónimo IMAP, es un protocolo de aplicación que permite en acceso a mensajes almacenados en un servidor de Internet. También se denomina "Protocolo de acceso a mensajes de Internet". Mediante IMAP se puede tener acceso al correo electrónico desde cualquier equipo que tenga una conexión a Internet. IMAP tiene varias ventajas sobre POP, que es el otro protocolo empleado para obtener correo desde un servidor. Por ejemplo, es posible especificar en IMAP carpetas del lado servidor. Por otro lado,

es más complejo que POP ya que permite visualizar los mensajes de manera remota y no descargando los mensajes como lo hace POP.

IMAP fue diseñado como una moderna alternativa a POP por Mark Crispin en el año 1986. Fundamentalmente, los dos protocolos les permiten a los clientes de correo acceder a los mensajes almacenados en un servidor de correo.

Ya sea empleando POP3 o IMAP4 para obtener los mensajes, los clientes utilizan SMTP para enviar mensajes. Los clientes de correo electrónico son comúnmente denominados clientes POP o IMAP, pero en ambos casos se utiliza SMTP

IRC

IRC (Internet Relay Chat) es un protocolo de comunicación en tiempo real basado en texto, que permite debates entre dos o más personas. Se diferencia de la mensajería instantánea en que los usuarios no deben acceder a establecer la comunicación de antemano, de tal forma que todos los usuarios que se encuentran en un canal pueden comunicarse entre sí, aunque no hayan tenido ningún contacto anterior. Las conversaciones se desarrollan en los llamados canales de IRC, designados por nombres que habitualmente comienzan con el carácter # o & (este último sólo es utilizado en canales locales del servidor). Es un sistema de charlas ampliamente utilizado por personas de todo el mundo.

Los usuarios del IRC utilizan una aplicación cliente para conectarse con un servidor, en el que funciona una aplicación IRCd (IRC daemon o servidor de IRC) que gestiona los canales y las conversaciones murales.

Después de la primera implementación de Jarkko Oikarinen, han surgido una gran cantidad de implementaciones distintas de clientes IRC, tanto como programas independientes, como mIRC, Irssi, Konversation o X-Chat de los más populares, como integradas dentro de otros programas, como Chatzilla.

Se destaca también la utilización de distintos scripts, los cuales tienen como finalidad tomar un cliente existente de IRC como plataforma para el desarrollo de distintos scripts los cuales añaden funcionalidades extra y facilitan la operación de diversos clientes IRC. En este caso se destacan Looksharp, NavIRC, IRCap, Xscript, entre otros.

LDAP

LDAP son las siglas de Lightweight Directory Access Protocol (en español Protocolo Ligero de Acceso a Directorios) que hacen referencia a un protocolo a nivel de aplicación que permite el acceso a un servicio de directorio ordenado y distribuido para buscar diversa información en un entorno de red. LDAP también se considera una base de datos (aunque su sistema de almacenamiento puede ser diferente) a la que pueden realizarse consultas.Habitualmente, almacena la información de autenticación (usuario y contraseña) y es utilizado para autenticarse aunque es posible almacenar otra información (datos de contacto del usuario, ubicación de diversos recursos de la red, permisos, certificados, etc). A manera de síntesis, LDAP es un protocolo de acceso unificado a un conjunto de información sobre una red.

MGCP

MGCP es un protocolo de control de dispositivos, donde un gateway esclavo (MG, Media Gateway) es controlado por un maestro (MGC, Media Gateway Controller, también llamado Call Agent).

MGCP, Media Gateway Control Protocol, es un protocolo interno de VoIP cuya arquitectura se diferencia del resto de los protocolos VoIP por ser del tipo cliente – servidor. MGCP está definido informalmente en la RFC 3435, y aunque no ostenta el rango de estándar, su sucesor, Megaco está aceptado y definido como una recomendación en la RFC 3015.

MGCP separa conceptualmente estas funciones en los tres elementos previamente señalados. Así, la conversión del contenido multimedia es realizada por el MG, el control de la señalización del lado IP es realizada por el MGC, y el control de la señalización del lado de la red de Conmutación de Circuitos es realizada por el SG.

MGCP introduce esta división en los roles con la intención de aliviar a la entidad encargada de transformar el audio para ambos lados, de las tareas de señalización, concentrando en el MGC el procesamiento de la señalización.

El control de calidad de servicio QoS se integra en el gateway GW o en el controlador de llamadas MGC. Este protocolo tiene su origen en el SGCP (de Cisco y Bellcore) e IPDC. Bellcore y Level3 plantearon el MGCP a varios organismos.

NNTP

Network News Transport Protocol (NNTP) es un protocolo inicialmente creado para la lectura y publicación de artículos de noticias en Usenet. Su traducción literal al español es "protocolo para la transferencia de noticias en red".

Para transferir noticias utilizaremos dos métodos:

Método pushing (activo): Cuando el cliente envía un artículo al servidor por este método, éste le devuelve un código de respuesta por el cual se sabe si ya tiene ese artículo, o sin embargo no lo tiene y es transferido desde el cliente. La orden para realizar dicho proceso es IHAVE msgid.

Este método también se llama coloquialmente empujar.

Cabe destacar una gran desventaja, y es que cada artículo es buscado individualmente, por lo que esto supone un gran número de accesos a la base de datos y una gran carga para el servidor.

Método pulling (pasivo): Con esta técnica se obtiene una lista de artículos de un grupo cuya fecha es posterior a la especificada por el cliente. Para ello se utiliza la orden NEWSNEWS. Después el cliente selecciona los artículos que no posee de la lista anterior, y le son transferidos. La orden ARTICLE sirve para realizar dicho propósito trabajando con cada uno de los IDs de los mensajes seleccionados.

Esta técnica también se puede llamar tirar.

Todo el proceso de transferencia de noticias está regulado por un estricto control por parte del servidor, ya que puede darse el caso de que exista información confidencial y ésta sólo puede ser vista por algunos clientes

BORDER GATEWAY PROTOCOL

Saltar a: navegación, búsqueda

En comunicaciones, BGP (del inglés Border Gateway Protocol) es un protocolo mediante el cual se intercambia información de encaminamiento o ruteo entre sistemas autónomos. Por ejemplo, los proveedores de servicio registrados en internet suelen componerse de varios sistemas autónomos y para este caso es necesario un protocolo como BGP.

Entre los sistemas autónomos de los ISP se intercambian sus tablas de rutas a través del protocolo BGP. Este intercambio de información de encaminamiento se hace entre los routers externos de cada sistema autónomo, los cuales deben soportar BGP. Se trata del protocolo más utilizado para redes con intención de configurar un Exterior Gateway Protocol.

La forma de configurar y delimitar la información que contiene e intercambia el protocolo BGP es creando lo que se conoce como sistema autónomo. Cada sistema autónomo (AS) tendrá conexiones o, mejor dicho, sesiones internas (iBGP) y además sesiones externas (eBGP).

El protocolo de gateway fronterizo (BGP) es un ejemplo de protocolo de gateway exterior (EGP). BGP intercambia información de encaminamiento entre sistemas autónomos a la vez que garantiza una elección de rutas libres de bucles. Es el protocolo principal de publicación de rutas utilizado por las compañías más importantes de ISP en Internet. BGP4 es la primera versión que admite encaminamiento entre dominios sin clase (CIDR) y agregado de rutas. A diferencia de los protocolos de Gateway internos (IGP), como RIP, OSPF y EIGRP, no usa métricas como número de saltos, ancho de banda, o retardo. En cambio, BGP toma decisiones de encaminamiento basándose en políticas de la red, o reglas que utilizan varios atributos de ruta BGP.

BGP realiza tres tipos de Ruteo:

Ruteo Interautónomo Ruteo Intrautónomo Ruteo de pasc.

NETWORK TIME PROTOCOL (NTP)

Network Time Protocol (NTP) es un protocolo de Internet para sincronizar los relojes de los sistemas informáticos a través del enrutamiento de paquetes en redes con latencia variable. NTP utiliza UDP como su capa de transporte, usando el puerto 123. Está diseñado para resistir los efectos de la latencia variable.NTP utiliza el Algoritmo de Marzullo con la escala de tiempo UTC, incluyendo soporte para características como segundos intercalares. NTPv4 puede mantenerse sincronizado con una diferencia máxima de 10 milisegundos (1/100 segundos) a través de Internet, y puede llegar a acercarse hasta 200 microsegundos (1/5000 segundos) o más en redes de área local sobre condiciones ideales.

POST OFFICE PROTOCOL (POP3)

Post Office Protocol (POP3, Protocolo de Oficina de Correo o "Protocolo de Oficina Postal") en clientes locales de correo para obtener los mensajes de correo electrónico almacenados en un servidor remoto. Es un protocolo de nivel de aplicación en el Modelo OSI.

Las versiones del protocolo POP, informalmente conocido como POP1 y POP2, se han hecho obsoletas debido a las últimas versiones de POP3. En general cuando se hace referencia al término POP, se refiere a POP3 dentro del contexto de protocolos de correo electrónico.1

Los clientes de correo electrónico que utilizan IMAP dejan por lo general los mensajes en el servidor hasta que el usuario los elimina directamente. Esto y otros factores hacen que la operación de IMAP permita a múltiples clientes acceder al mismo buzón de correo. La mayoría de los clientes de correo electrónico soportan POP3 ó IMAP; sin embargo, solo unos cuantos proveedores de internet ofrecen IMAP como valor agregado de sus servicios.

PROCEDIMIENTO REMOTO (RPC)

La Llamada a Procedimiento Remoto (RPC) (del inglés, Remote Procedure Call) es un protocolo que permite a un programa de ordenador ejecutar código en otra máquina remota sin tener que preocuparse por las comunicaciones entre ambos. El protocolo es un gran avance sobre los sockets usados hasta el momento. De esta manera el programador no tenía que estar pendiente de las comunicaciones, estando éstas encapsuladas dentro de las RPC.

Las RPC son muy utilizadas dentro de la comunicación cliente-servidor. Siendo el cliente el que inicia el proceso solicitando al servidor que ejecute cierto procedimiento o función y enviando éste de vuelta el resultado de dicha operación al cliente.

Hay distintos tipos de RPC, muchos de ellos estandarizados como pueden ser el RPC de Sun denominado ONC RPC (RFC 1057), el RPC de OSF denominado DCE/RPC y el Modelo de Objetos de Componentes Distribuidos de Microsoft DCOM, aunque ninguno de estos es compatible entre sí. La mayoría de ellos utilizan un lenguaje de descripción de interfaz (IDL) que define los métodos exportados por el servidor.

Hoy en día se está utilizando el XML como lenguaje para definir el IDL y el HTTP como protocolo de red, dando lugar a lo que se conoce como servicios web. Ejemplos de éstos pueden ser SOAP o XML-RPC.

TIPOS DE SEMÁNTICA

SEMÁNTICA TAL-VEZ

Procedimiento remoto puede ejecutarse una vez o ninguna vez. El cliente puede recibir una respuesta o ninguna.

Funcionamiento

1. El cliente envía una petición y se queda a la espera un tiempo determinado.2. Si no llega la respuesta dentro del tiempo de espera, continúa su ejecución.3. El cliente no tiene realimentación en caso de fallo (no sabe que pasó).

Sólo admisible en aplicaciones donde se tolere la pérdida de peticiones y la recepción de respuestas con retraso (fuera de orden).

SEMÁNTICA AL-MENOS-UNA-VEZ

Procedimiento remoto se ejecuta una o más veces.

El cliente puede recibir una o más respuestas.

Funcionamiento

1. El cliente envía una petición y queda a la espera un tiempo.2. Si no llega respuesta o ACK dentro del tiempo de espera, repite la

petición.3. El servidor no filtra peticiones duplicadas (el procedimiento remoto puede

ejecutarse repetidas veces).4. El cliente puede recibir varias respuestas.

Sólo es aplicable cuando se usan exclusivamente operaciones idempotentes (repetibles). Nota: Una operación es idempotente si se puede ejecutar varias veces resultando el mismo efecto que si se hubiera ejecutado sólo una. En ocasiones una operación no idempotente puede implementarse como una secuencia de operaciones idempotentes. Admisible en aplicaciones donde se tolere que se puedan repetir invocaciones sin afectar a su funcionamiento.

SEMÁNTICA COMO-MÁXIMO-UNA-VEZ

El procedimiento remoto se ejecuta exactamente una vez o no llega a ejecutarse ninguna.

El cliente recibe una respuesta o una indicación de que no se ha ejecutado el procedimento remoto.

Funcionamiento

1. El cliente envía la petición y queda a la espera un tiempo.2. Si no llega respuesta o ACK dentro del tiempo de espera, repite la petición.3. El servidor filtra las peticiones duplicadas y guarda historial con las

respuestas enviadas (servidor con memoria). El procedimiento remoto sólo se ejecuta una vez.

4. El cliente sólo recibe una respuesta si la petición llegó y se ejecutó el procedimiento, si no recibe informe del error.

CONCLUSIÓN

La conclusión a la que se ha llegado tras realizar este trabajo ha sido la siguiente: El conjunto de protocolos de las capas diseñadas por la IETF ha sido de vital importancia para el desarrollo de las redes de comunicación, sobre todo para Internet. El ritmo de expansión de Internet también es una consecuencia de estos protocolos, sin los cuales, conectar redes de distintas naturalezas (diferente Hardware, sistema operativo, etc...), hubiera sido mucho más difícil, por no decir imposible. Así pues, podemos decir que los protocolos TCP/IP fueron y son el motor necesario para que las redes en general, e Internet en particular, se mejoren y se pueda lograr una buena "autopista de la información".