RFCs (1918, 790, 791,792 793, 1180, 2131, 1034, 1035, 2616, 959 Y 5321)

 RFC 1918

Aunque la mayoría de las direcciones IPv4 de host son direcciones públicas designadas para uso en redes a las que se accede desde Internet, existen bloques de direcciones que se utilizan en redes que requieren o no acceso limitado a Internet. Estas direcciones se denominan direcciones privadas.

Las direcciones privadas se definen en RFC 1918, Asignación de direcciones para redes de Internet privadas, y en ocasiones se hace referencia a ellas como direcciones RFC 1918. Los bloques de direcciones de espacio privado, como se muestra en la ilustración, se utilizan en redes privadas. Los hosts que no requieren acceso a Internet pueden utilizar direcciones privadas. Sin embargo, dentro de la red privada, los hosts aún requieren direcciones IP únicas dentro del espacio privado.

Hosts en distintas redes pueden utilizar las mismas direcciones de espacio privado. Los paquetes que utilizan estas direcciones como la dirección de origen o de destino no deberían aparecer en la Internet pública. El router o el dispositivo de firewall del perímetro de estas redes privadas deben bloquear o convertir estas direcciones. Incluso si estos paquetes fueran a llegar hasta Internet, los routers no tendrían rutas para reenviarlos a la red privada correcta.

En RFC 6598, IANA reservó otro grupo de direcciones conocidas como “espacio de dirección compartido”. Como sucede con el espacio de dirección privado definido en RFC 1918, las direcciones del espacio de dirección compartido no son enrutables globalmente. Sin embargo, el propósito de estas direcciones es solamente ser utilizadas en redes de proveedores de servicios. El bloque de direcciones compartido es 100.64.0.0/10.

Direcciones privadas:

Los bloques de direcciones privadas son:

10.0.0.0 a 10.255.255.255 (10.0.0.0/8)

172.16.0.0 a 172.31.255.255 (172.16.0.0/12)

192.168.0.0 a 192.168.255.255 (192.168.0.0/16)

Direcciones públicas

La amplia mayoría de las direcciones en el rango de host unicast IPv4 son direcciones públicas. Estas direcciones están diseñadas para ser utilizadas en los hosts de acceso público desde Internet. Aun dentro de estos bloques de direcciones IPv4, existen muchas direcciones designadas para otros fines específicos.

RFC 790 y RFC 791

Lanzadas en 1981, RFC 790 y RFC 791 describen cómo se asignaron inicialmente las direcciones de red IPv4 según un sistema de clasificación. En la especificación original de IPv4, los autores establecieron las clases para proporcionar tres tamaños distintos de redes para organizaciones grandes, medianas y pequeñas. Por consiguiente, se definieron las direcciones de clase A, B y C con un formato específico para los bits de orden superior. Los bits de orden superior son los bits del extremo izquierdo en una dirección de 32 bits.

Como se muestra en la figura:

·         Direcciones de clase A que comienzan con 0: diseñadas para organizaciones grandes. Esta clase incluye todas las direcciones de 0.0.0.0 (00000000) a 127.255.255.255 (01111111). La dirección 0.0.0.0 se reserva para el routing predeterminado y la dirección 127.0.0.0, para la prueba de loopback.

·         Direcciones de clase B que comienzan con 10: diseñadas para organizaciones medianas a grandes. Esta clase incluye todas las direcciones de 128.0.0.0 (10000000) a 191.255.255.255 (10111111).

·         Direcciones de clase C que comienzan con 110: diseñadas para organizaciones pequeñas a medianas. Esta clase incluye todas las direcciones de 192.0.0.0 (11000000) a 223.255.255.255 (11011111).

Las direcciones restantes se reservaron para multicasting y futuros usos.

·         Direcciones de multidifusión de clase D que comienzan con 1110: las direcciones de multidifusión se utilizan para identificar un grupo de hosts que forman parte de un grupo de multidifusión. Esto ayuda a reducir la cantidad de procesamientos de paquetes que realizan los hosts, en especial en los medios de difusión (es decir, las LAN Ethernet). Los protocolos de routing, como RIPv2, EIGRP y OSPF, utilizan direcciones de multidifusión designadas (RIP = 224.0.0.9, EIGRP = 224.0.0.10, OSPF 224.0.0.5 y 224.0.0.6).

·         Direcciones IP de clase E reservadas que comienzan con 1111: estas direcciones se reservaron para uso experimental y futuro.

RFC 792

 

Protocolo de control de mensajes de Internet

 

El protocolo de mensajes de control de Internet (en inglés: Internet Control Message Protocol y conocido por sus siglas ICMP) es parte del conjunto de protocolos IP. Es utilizado para enviar mensajes de error e información operativa indicando, por ejemplo, que un host no puede ser localizado o que un servicio que se ha solicitado no está disponible. Estos mensajes del protocolo ICMP se envían a la dirección IP de origen del paquete.

Siendo un protocolo de la "Capa de Red" ICMP difiere de los protocolos de la "Capa de Transporte" (tales como TCP y UDP), en que no es generalmente usado para intercambiar información entre sistemas, ni tampoco por las aplicaciones de usuario (con excepción de algunas herramientas como ping y traceroute, que emplean mensajes ICMP con fines de diagnóstico).

Aspectos técnicos

Este protocolo es parte del conjunto de protocolos IP, y de esa manera se lo define en la RFC 792. Los mensajes ICMP son comúnmente empleados con fines de diagnóstico y control, o generados en respuesta a errores en las operaciones IP (como se especifica en el RFC 1122), y se envían a la dirección IP de origen del paquete que dio lugar a la generación del mensaje ICMP.

La versión de ICMP para IPv4 también es conocida como ICMPv4. IPv6 tiene su protocolo equivalente ICMPv6.

El protocolo se emplea cuando un host no puede ser alcanzado, cuando el tiempo de vida de un paquete ha expirado, cuando un servicio solicitado no está disponible, etc. Es decir, se usa para manejar mensajes de error y control necesarios en los sistemas de red informando a la fuente original para que evite o corrija el problema detectado.

A modo de ejemplo, cada router que reenvía un datagrama IP tiene que disminuir el campo de tiempo de vida (TTL) de la cabecera IP en una unidad; si el TTL llega a cero, un mensaje ICMP tipo 11 ("Tiempo excedido") es enviado al originador del datagrama.

Los mensajes ICMP son construidos en el nivel de la "Capa de Red". Así, IP encapsula el mensaje ICMP con una nueva cabecera (para obtener los mensajes de respuesta desde el host original), y transmite el datagrama resultante de la manera habitual. Cada mensaje ICMP es encapsulado en un solo datagrama IP, por lo que la entrega del mismo no está garantizada.

Si bien ICMP emplea el soporte básico de IP como si fuese un protocolo de más alto nivel es, en realidad, una parte integral de IP. A pesar de estar encapsulados en paquetes comunes, los mensajes ICMP habitualmente se procesan de forma especial recibiendo un tratamiento diferente al del procesamiento IP normal. En muchos casos es necesario analizar el contenido del mensaje ICMP para determinar el tipo de error apropiado que debe enviarse a la aplicación responsable de transmitir el paquete IP que solicitara el envío del mensaje ICMP.

Muchas de las utilidades de red comunes están basadas en los mensajes ICMP. El comando traceroute puede implementarse transmitiendo datagramas con valores especiales de TTL en la cabecera, y analizando luego los mensajes de "Destino inalcanzable" y "Tiempo excedido" (tipos 3 y 11) generados como respuesta. La herramienta ping está implementada utilizando los mensajes "Echo request" y "Echo reply" de ICMP.

Estructura de un segmento ICMP

El ICMP inicia después del IPv4 cabecera y se identifica con el protocolo número “1”. Todos los paquetes ICMP tendrán una cabecera de 8 bytes y la sección de datos de tamaño variable. Los primeros 4 bytes de la cabecera serán consistentes. El primer byte es reservado para el tipo de ICMP. El segundo octeto es para el código de ICMP. El tercer y cuarto byte es una suma de comprobación de todo el mensaje ICMP. El contenido de los restantes 4 bytes de la cabecera pueden variar dependiendo de la función del tipo y el código ICMP.

Los mensajes de error de este protocolo contienen una sección de datos que incluye todos los IP de cabecera más los 8 primeros bytes de los datos del paquete IP que ha causado el mensaje de error. El paquete ICMP es encapsulado en un nuevo paquete IP.

Bits 0-7 8-15 16-23 24-31

0 Tipo Código Checksum

32 Resto del encabezado 

Tipo - Tipo de ICMP como se especifica a continuación.

Código - Subtipo al tipo dado.

Checksum - Datos comprobación de errores. Calculado a partir de la cabecera ICMP + datos, con un valor de 0 para este campo. El algoritmo de suma de comprobación se especifica en RFC 1071.

Resto del Header - Cuatro campo byte. Puede variar en función del tipo y código ICMP.

Mensajes de Control

Echo Reply

Un Echo Reply (Respuesta de Eco) en el protocolo ICMP es un mensaje generado como respuesta a un mensaje Echo Request (petición de Eco).

Formato del Mensaje:

Encapsulación

Lista de mensajes de control permitidos (incompleta):

 

0 - Echo Reply

1 - Reservado

2 - Reservado

3 - Destination Unreachable

4 - Source Quench

5 - Redirect Message

6 - Dirección Alterna de Host

7 - Reservado

8 - Echo Request

9 - Anuncio de Router

10 - Solicitud de Router

11 - Tiempo Excedido

12 - Problema de Parámetro

13 - Marca de tiempo

14 - Respuesta de Marca de tiempo

15 - Petición de Información

16 - Respuesta de Información

17 - Petición de Máscara de Dirección

18 - Respuesta de Máscara de Dirección

19 - Reservado para seguridad

20-29 - Reservado para experimentos de robustez

30 - Traceroute

31 - Error de Conversión de Datagrama

32 - Redirección de Host Móvil

33 - IPv6 ¿Dónde estas?

34 - IPv6 Estoy aquí

35 - Petición de Registro de Móvil

36 - Respuesta de registro de Móvil

37 - Petición de Nombre de Dominio

38 - Respuesta de Nombre de Dominio

39 - SKIP Protocolo de Algoritmo de Descubrimiento

40 - Photuris, Fallas de Seguridad

41-255 – Reservado

RFC 793

TCP es un protocolo estándar con número 7 de STD. TCP se describe en el RFC 793 - Protocolo de Control de Transmisión. Este protocolo se recomienda, pero en la práctica cada implementación de TCP/IP que no se use exclusivamente para encaminamiento incluirán TCP.

TCP proporciona muchas más facilidades para las aplicaciones que UDP, recuperación de errores, control de flujo y confiabilidad. Es un protocolo orientado a conexión en contraposición a UDP que no lo es. La mayoría de los protocolos de las aplicaciones de usuario, como TELNET y FTP, utiliza TCP.

Sockets

El concepto de socket se discutió anteriormente en Puertos y sockets.

Dos procesos se comunican a través de sockets TCP. El modelo de socket proporciona a un proceso una conexión full-duplex con otro proceso. La aplicación no necesita manejar el flujo de datos en la conexión; estas facilidades las proporciona TCP.

TCP utiliza el mismo principio que UDP (ver Puertos) para proporcionar multiplexación. Como UDP, usa los puertos conocidos y efímeros. Cado extremo de una conexión TCP tiene un socket que se puede indentificar por la tripleta <TCP, dirección IP, número de puerto>. A esto también se le demomina half-association. Si dos procesos están comunicados por TCP, poseen una conexión lógica que se identifica unívocamente por los dos sockets implicados, es decir, por la combinación <TCP, dirección IP local, puerto local, dirección IP remota, puerto remoto>. Ver Figura - Conexión TCP. Los procesos servidores son capaces de gestionar múltiples conversaciones por un único puerto.

Concepto TCP

Como se citó anteriormente, el propósito primordial de TCP es proporcionar circuitos lógicos confiables o servicios de conexión entre parejas de procesos. Esto no implica confiabilidad desde protocolos de más bajo nivel (como IP) así que TCP debe garantizar esto por sí mismo.

TCP se puede caracterizar por las siguientes facilidades que proporciona a las aplicaciones que hacen uso de él:

Tranferencia de flujos de datos. Desde el punto de vista de la aplicación, TCP transfiere un flujo de bytes contiguo a través de internet. La aplicación no tiene que molestarse troceyo los datos en bloques básicos o datagramas. TCP hace esto agrupando los bytes en segmentos TCP, que se transfieren a IP para transmitirlos al destino. TCP decide también por sí mismo cómo segmentar los datos y debe dirigir los datos a su propia conveniencia.

A veces, una aplicación necesita estar segura de que todos los datos pasados a TCP han llegado al destino. Por esta razón, se define una función push. Esta push todos los segmentos TCP restantes que están almacenados en el host destino. La función close connection normal también pushes los datos hacia el destino.

Confiabilidad. TCP asigna un número de secuencia a cada byte transmitido y espera por un reconocimiento positivo (ACK) del receptor TCP. Si el ACK no se recibe en un intervalo fijado, los datos se retransmiten. Como los datos se transmiten en bloques (segmentos TCP) sólo el número de secuencia del primer byte de datos en los segmentos se envían al host destino.

El receptor TCP utiliza los números de secuencia para reorganizar los segmentos cuyo lleguen fuera de orden y para eliminar segmentos duplicados.

Control de flujo. El receptor TCP, cuyo envía un ACK de vuelta al emisor, también indica al emisor el número de bytes que puede recibir más allá del último segmento TCP recibido sin causar ni overrun ni desbordamiento en sus búferes internos. Este se envía en el ACK de forma of the highest sequence number it puede recibir sin problemas. Este mecanismo también se denomina mecanismo ventana y se discutirá con más detalle más tarde en este mismo capítulo.

Multiplexación. Se logra usando puertos, como en UDP.

Conexiones lógicas. La confiabilidad y los mecanismos de control de flujo descritos anteriormente requieren que TCP inicializa y mantenga cierta información de estado para cada "flujo de datos". La combinación de este estado, incluyendo sockets, números de secuencia y tamaños de ventana, se llama conexión lógica. Cada conexión se identifica unívocamente por la pareja de sockets usados por los procesos emisor y receptor.

Full Duplex. TCP proporciona flujos de datos concurrentes en ambas direcciones.

El principio de ventana

Un protocolo de transporte simple debe usar el principio siguiente: enviar un paquete y luego esperar por un reconocimiento del receptor antes de que envíe el próximo paquete. Si el ACK no se recibe en un tiempo razonable, retransmite el paquete.

Aunque este mecanismo asegura confiabilidad, únicamente utiliza una parte del ancho de banda de la red.

Considerar ahora un protocolo donde los grupos emisores its paquetes to be transmitted as:

Datagramas IP con segmentos TCP

Los segmentos TCP se transportan en datagramas IP con los siguientes parámetros:

 

              Tipo de Servicio = 00000000

                esto es: Rutina de precedencia

                         Retardo     = normal

                         Rendimiento = normal

 

              Tiempo de vida = 00111100 (1 minuto)

Interfaz de Programación de Aplicaciones TCP

La interfaz de programación de aplicaciones de TCP no está totalmente definida. Sólo se definen algunas funciones base. El RFC 793 - Protocolo de Control de Transmisión proporciona únicamente la descripciñon de algunas de estas funciones base. Como es el caso de la mayoría de los RFCs, en la familia de protocolos TCP/IP, se deja un alto grado de libertad a los implementadores, thereby permitiendo implementaciones óptimas (depende del sistema operativo), resultando con mejor eficiencia (mayor rendimiento).

 

Las siguientes llamadas a funciones se describen en el RFC:

 

Abrir

Para establecer la conexión se tiene en cuenta muchos parámetros:

·         Activo/pasivo

·         Socket ajeno

·         Número de puerto local

·         Valor de timeout (opcional)

·         Y muchas otras opciones

Retorna un nombre de conexión local que se usa para referenciar una conexión particular en todas las otras funciones.

Enviar

Causa que los datos en un búfer de usuario referenciado para enviar por encima de la conexión. Se puede activar el flag de URGENT o el de PUSH.

Recibir

Copia los datos provenientes TCP al búfer de usuario.

Cerrar

Cierra la conexión; causa un push de todos los datos restantes y un segmento TCP con el flag FIN activado.

Estado

Es una llamada que depende de la implementación que retorna información como:

Socket local y ajeno

Envía y recibe tamaños de ventana

Estado de la conexión

Nombre de la conexión local

Abortar

Causa que todas las operaciones pendientes de enviar y recibir se aborten. Se envía un RESET al TCP ajeno.

 

 

RFC2131

Protocolo de configuración dinámica de host

 

El protocolo de configuración dinámica de host (en inglés: Dynamic Host Configuration Protocol, también conocido por sus siglas de DHCP), desarrollado a partir de 1985 como extensión de BOOTP, es un protocolo de red de tipo cliente/servidor1​ mediante el cual un servidor DHCP asigna dinámicamente una dirección IP y otros parámetros de configuración de red a cada dispositivo en una red para que puedan comunicarse con otras redes IP. Este servidor posee una lista de direcciones IP dinámicas y las va asignando a los clientes conforme estas van quedando 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. Así los clientes de una red IP pueden conseguir sus parámetros de configuración automáticamente. Este protocolo por primera vez se publicó en octubre de 1993 (RFC 1531) y su implementación actual para IPv4 está en la RFC 2131 (marzo de 1997); para IPv6 está descrita en RFC 3315 (julio de 2003).

Asignación de direcciones IP

Cada dirección IP debe configurarse manualmente en cada dispositivo y, si el dispositivo se mueve a otra subred, se debe configurar otra dirección IP diferente. El DHCP le permite al administrador supervisar y distribuir de forma centralizada las direcciones IP necesarias y, automáticamente, asignar y enviar una nueva IP si fuera el caso en que el dispositivo es conectado en un lugar diferente de la red.

El protocolo DHCP incluye tres métodos de asignación de direcciones IP:

Asignación manual o estática

Asigna una dirección IP a una máquina determinada. Se suele utilizar cuando se quiere controlar la asignación de dirección IP a cada cliente, y evitar, también, que se conecten clientes no identificados.

Asignación automática

Asigna una dirección IP a una máquina cliente la primera vez que hace la solicitud al servidor DHCP y hasta que el cliente la libera. Se suele utilizar cuando el número de clientes no varía demasiado.

Asignación dinámica

El único método que permite la reutilización dinámica de las direcciones IP. El administrador de la red determina un rango de direcciones IP y cada dispositivo conectado a la red está configurado para solicitar su dirección IP al servidor cuando la tarjeta de interfaz de red se inicializa. El procedimiento usa un concepto muy simple en un intervalo de tiempo controlable. Esto facilita la instalación de nuevas máquinas clientes.

Algunas implementaciones de DHCP pueden actualizar el DNS asociado con los servidores para reflejar las nuevas direcciones IP mediante el protocolo de actualización de DNS establecido en RFC 2136 (Inglés).

El DHCP es una alternativa a otros protocolos de gestión de direcciones IP de red, como el BOOTP (Bootstrap Protocol). DHCP es un protocolo más avanzado, pero ambos son los usados normalmente.

En Windows 98 y posteriores, cuando el DHCP es incapaz de asignar una dirección IP, se utiliza un proceso llamado "Automatic Private Internet Protocol Addressing".

 

Parámetros configurables

Artículo principal: Parámetros DHCP

Un servidor DHCP puede proveer de una configuración opcional al dispositivo cliente. Dichas opciones están definidas en el RFC 2132. Algunas de las opciones configurables son:

 

·         Dirección del servidor DNS

·         Nombre DNS

·         Puerta de enlace de la dirección IP

·         Dirección de Publicación Masiva (broadcast address)

·         Máscara de subred

·         Tiempo máximo de espera del ARP (Protocolo de Resolución de Direcciones según siglas en inglés)

·         MTU (Unidad de Transferencia Máxima según siglas en inglés) para la interfaz

·         Servidores NIS (Servicio de Información de Red según siglas en inglés)

·         Dominios NIS

·         Servidores NTP (Protocolo de Tiempo de Red según siglas en inglés)

·         Servidor SMTP

·         Servidor TFTP

·         Nombre del servidor de nombres de Windows (WINS)

 

Anatomía del protocolo

 

Esquema de una sesión típica DHCP.

(Autoridad de Números Asignados en Internet según siglas en inglés) en BOOTP: 67/UDP para las computadoras servidor y 68/UDP para los clientes.

 

A continuación, se describe la secuencia de intercambio de mensajes entre el cliente DHCP y el servidor DHCP.

 

DHCP Discovery

Artículo principal: DHCP Discovery

DHCP Discovery es una solicitud DHCP realizada por un cliente de este protocolo para que el servidor DHCP de dicha red de computadoras le asigne una dirección IP y otros Parámetros DHCP como la máscara de red o el nombre DNS.5​ La solicitud va contenida en un mensaje de descubrimiento que se difunde a todas las máquinas en la red.

 

DHCP Offer

Es el paquete de respuesta del Servidor DHCP a un cliente DHCP ante su petición de la asignación de los Parámetros DHCP. Para ello involucra su dirección MAC (Media Access Control). Este mensaje contiene una dirección IP disponible que el servidor está dispuesto a asignar al cliente, junto con los otros parámetros de configuración. El servidor puede enviar múltiples ofertas de asignación de direcciones IP y otros parámetros de configuración al cliente.

DHCP Request

Después de recibir las ofertas, el cliente DHCP selecciona una oferta específica de los paquetes recibidos de DHCP Offer. El cliente envía un mensaje de solicitud al servidor DHCP correspondiente, indicando que desea aceptar esa oferta en particular. El mensaje contiene la dirección IP de la foferta seleccionada

 

 

 

DHCP Acknowledge

Artículo principal: DHCP Acknowledge

Al recibir el mensaje de solicitud del cliente, el servidor la reconoce y le envía un acuse de recibo o mensaje de aceptación DHCP, se inicia la fase final del proceso de configuración. Esta fase implica el reconocimiento con el envío de un paquete al cliente. Este paquete confirma que la dirección IP solicitada ha sido asignada al cliente e incluye la duración de la conexión y cualquier otra información de configuración que el cliente pueda tener solicitada. En este punto, el proceso de configuración TCP/IP se ha completado. El servidor reconoce la solicitud y la envía acuse de recibo al cliente. El sistema en su conjunto espera que el cliente configure su interfaz de red con las opciones suministradas. El servidor DHCP responde a la DHCPREQUEST con un DHCPACK, completando así el ciclo de iniciación. La dirección origen es la dirección IP del servidor de DHCP y la dirección de destino es todavía 255.255.255.255. El campo YIADDR contiene la dirección del cliente, y los campos CHADDR y DHCP: Client Identifier campos son la dirección física de la tarjeta de red en el cliente. La sección de opciones del DHCP identifica el paquete como un ACK.

Confidencialidad

En un contexto de proveedor de Internet, los registros DHCP de asignación de direcciones o bien contienen o están vinculadas a información de identificación personal confidencial, los datos de contacto del cliente. Estos son atractivos para los spammers, y podrían ser buscados para "expediciones de pesca" por las agencias de policía o litigantes. Por lo menos una aplicación[cita requerida] imita la política de Canadian Library Association para la circulación del libro y no retiene información de identificación una vez que el "préstamo" ha terminado.

Parámetros de configuración del cliente

El servidor DHCP puede proporcionar parámetros de configuración opcionales para el cliente. El RFC 2132 describe las opciones de DHCP disponibles definidas por Internet Assigned Numbers Authority (IANA) - Parámetros DHCP y BOOTP.6​

Un cliente DHCP puede seleccionar, manipular y sobrescribir los parámetros proporcionados por un servidor DHCP.7

RFC 1034 - RFC 1035

El Sistema de Nombres de Dominio (DNS) es un sistema de nombres jerárquico descentralizado para computadoras, servicios o cualquier recurso conectado a Internet o a una red privada. Asocia diversa información con nombres de dominio asignados a cada una de las entidades participantes. Lo más destacado es que traduce nombres de dominio más fáciles de memorizar a las direcciones IP numéricas necesarias con el fin de localizar e identificar servicios y dispositivos informáticos con los protocolos de red subyacentes. Al proporcionar un servicio de directorio distribuido a nivel mundial, el Sistema de nombres de dominio es un componente esencial de la funcionalidad de Internet.

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.

La asignación de nombres a direcciones IP es ciertamente la función más conocida de los protocolos DNS. Por ejemplo, si la dirección IP del sitio Google es 216.58.210.163, la mayoría de la gente llega a este equipo especificando www.google.com y no la dirección IP. Además de ser más fácil de recordar, el nombre es más fiable.3​ La dirección numérica podría cambiar por muchas razones, sin que tenga que cambiar el nombre del sitio web. Incluso, en el caso de que una página web utilice una red de distribución de contenidos (Content delivery network o CDN, por sus siglas en inglés) por medio del DNS el usuario recibirá la dirección IP del servidor más cercano según su localización geográfica (cada CDN a su vez tiene sus propios servidores DNS).

 

Componentes

Para la operación práctica del sistema DNS se utilizan tres componentes principales:

 

Clientes fase 1

Un programa cliente DNS que se ejecuta en la computadora del usuario y que genera peticiones DNS de resolución de nombres a un servidor DNS (Por ejemplo: ¿Qué dirección IP corresponde a nombre.dominio?)

Servidores DNS

Que contestan las peticiones de los clientes. Los servidores recursivos tienen la capacidad de reenviar la petición a otro servidor si no disponen de la dirección solicitada.

Zonas de autoridad

Es una parte del espacio de nombre de dominios sobre la que es responsable un servidor DNS, que puede tener autoridad sobre varias zonas. (Por ejemplo: subdominio.Wikipedia.ORG, subdominio.COM, etc.)

Entendiendo las partes de un nombre de dominio

Un nombre de dominio usualmente consiste en dos o más partes (técnicamente «etiquetas»), separadas por puntos cuando se las escribe en forma de texto. Por ejemplo, www.ejemplo.com o es.wikipedia.org

A la etiqueta ubicada más a la derecha se le llama «dominio de nivel superior» (en inglés top level domain). Como «com» en www.ejemplo.com u «org» en es.wikipedia.org

Cada etiqueta a la izquierda especifica una subdivisión o «subdominio». Nótese que «subdominio» expresa dependencia relativa, no dependencia absoluta. En teoría, esta subdivisión puede tener hasta 127 niveles, y cada etiqueta puede contener hasta 63 caracteres, pero restringidos a que la longitud total del nombre del dominio no exceda los 255 caracteres, aunque en la práctica los dominios son casi siempre mucho más cortos.

Finalmente, la parte más a la izquierda del dominio suele expresar el nombre de la máquina (en inglés hostname). El resto del nombre de dominio simplemente especifica la manera de crear una ruta lógica a la información requerida. Por ejemplo, el dominio es.wikipedia.org tendría el nombre de la máquina «es», aunque en este caso no se refiere a una máquina física en particular.

El DNS consiste en un conjunto jerárquico de servidores DNS. Cada dominio o subdominio tiene una o más «zonas de autoridad» que publican la información acerca del dominio y los nombres de servicios de cualquier dominio incluido. La jerarquía de las zonas de autoridad coincide con la jerarquía de los dominios. Al inicio de esa jerarquía se encuentra los servidores raíz: los servidores que responden cuando se busca resolver un dominio de primer y segundo nivel.

DNS en el mundo real

Los usuarios generalmente no se comunican directamente con el servidor DNS: la resolución de nombres se hace de forma transparente por las aplicaciones del cliente (por ejemplo, navegadores, clientes de correo y otras aplicaciones que usan Internet). Al realizar una petición que requiere una búsqueda de DNS, la petición se envía al servidor DNS local del sistema operativo. El sistema operativo, antes de establecer alguna comunicación, comprueba si la respuesta se encuentra en la memoria caché. En el caso de que no se encuentre, la petición se enviará a uno o más servidores DNS,9​ el usuario puede utilizar los servidores propios de su ISP, puede usar un servicio gratuito de resolución de dominios o contratar un servicio avanzado de pago que por lo general son servicios contratados por empresas por su rapidez y la seguridad que estos ofrecen.

La mayoría de usuarios domésticos utilizan como servidor DNS el proporcionado por el proveedor de servicios de Internet salvo quienes personalizan sus equipos o enrutadores para servidores públicos determinados. La dirección de estos servidores puede ser configurada de forma manual o automática mediante DHCP (IP dinámica). En otros casos, los administradores de red tienen configurados sus propios servidores DNS.

En cualquier caso, los servidores DNS que reciben la petición, buscan en primer lugar si disponen de la respuesta en la memoria caché. Si es así, sirven la respuesta; en caso contrario, iniciarían la búsqueda de manera recursiva. Una vez encontrada la respuesta, el servidor DNS guardará el resultado en su memoria caché para futuros usos y devuelve el resultado.9​

 

Típicamente el protocolo DNS transporta las peticiones y respuestas entre cliente y servidor usando el protocolo UDP, ya que es mucho más rápido. Las ocasiones donde se usa el protocolo TCP son: cuando se necesitan transportar respuestas mayores de 512 bytes de longitud (por ejemplo al usar DNSSEC) y cuando se intercambia información entre servidores (por ejemplo al hacer una transferencia de zona), por razones de fiabilidad.

Jerarquía DNS

Árbol DNS

El espacio de nombres de dominio tiene una estructura arborescente. Las hojas y los nodos del árbol se utilizan como etiquetas de los medios. Un nombre de dominio completo de un objeto consiste en la concatenación de todas las etiquetas de un camino. Las etiquetas son cadenas alfanuméricas (con «-» como único símbolo permitido), deben contar con al menos un carácter y un máximo de 63 caracteres de longitud, y deberá comenzar con una letra (y no con «-»).11​ Las etiquetas individuales están separadas por puntos. Un nombre de dominio termina con un punto (aunque este último punto generalmente se omite, ya que es puramente formal). Un nombre de dominio correctamente formado (FQDN, por sus siglas en inglés), es por ejemplo este: www.ejemplo.com. (incluyendo el punto al final).

Un nombre de dominio debe incluir todos los puntos y tiene una longitud máxima de 255 caracteres.

Un nombre de dominio se escribe siempre de derecha a izquierda. El punto en el extremo derecho de un nombre de dominio separa la etiqueta raíz de la jerarquía. Este primer nivel es también conocido como dominio de nivel superior (TLD, por sus siglas en inglés).

Los objetos de un dominio DNS (por ejemplo, el nombre del equipo) se registran en un archivo de zona, ubicado en uno o más servidores de nombres.

Tipos de servidores DNS

Estos son los tipos de servidores de acuerdo a su función:

Primarios o maestros

guardan los datos de un espacio de nombres en sus ficheros.

Secundarios o esclavos

obtienen los datos de los servidores primarios a través de una transferencia de zona.

Locales o caché

funcionan con el mismo software, pero no contienen la base de datos para la resolución de nombres. Cuando se les realiza una consulta, estos a su vez consultan a los servidores DNS correspondientes, almacenando la respuesta en su base de datos para agilizar la repetición de estas peticiones en el futuro continuo o libre.

Tipos de resolución de nombres de dominio

Un servidor DNS puede resolver un nombre de dominio de manera «recursiva» o «iterativa».12​ En una consulta «iterativa», un cliente solicita a un servidor DNS que obtenga por sí mismo la respuesta completa (es decir, dado el dominio mi.dominio.com, el cliente espera recibir la dirección IP correspondiente). Por otro lado, dada una consulta «recursiva», el servidor DNS no otorga una respuesta completa: para el caso de mi.dominio.com, el primer servidor al que se le realiza la consulta (un servidor raíz), retorna las direcciones IP de los servidores de nivel superior (TDL) responsables del dominio .com. De este modo, el cliente ahora debe realizar una nueva consulta a uno de estos servidores, el cual toma nota del sufijo .dominio.com y responde con la IP del servidor DNS correspondiente, por ejemplo dns.dominio.com. Finalmente, el cliente envía una nueva consulta a dns.dominio.com para obtener la dirección IP de mi.dominio.com.

 

En la práctica, la consulta de un host a un DNS local es recursiva, mientras que las consultas que realiza el DNS local son iterativas. Además, las consultas recursiva sólo se realizan en caso de que el servidor DNS local no posea los datos correspondientes en caché (o en caso de que estos hayan expirado). En resumen, el proceso de resolución normal se lleva a cabo de la siguiente manera:

 

·         El servidor DNS local recibe una consulta recursiva desde el resolver del host cliente.

·         El servidor DNS local verifica su caché para ver si ya tiene una respuesta almacenada para esa consulta. Si la encuentra, devuelve la respuesta al cliente.

·         Si el servidor DNS local no tiene la respuesta en su caché, realiza las consultas iterativas a los servidores correspondientes.

·         El servidor DNS local entrega la resolución al host que solicitó la información.

·         El resolver del host cliente entrega la respuesta a la aplicación correspondiente.

 

RFC 2616

Protocolo de transferencia de hipertexto

El protocolo de transferencia de hipertexto (en inglés: Hypertext Transfer Protocol, abreviado HTTP) es el protocolo de comunicación que permite las transferencias de información a través de archivos (XML, HTML…) en la World Wide Web. Fue desarrollado por el World Wide Web Consortium y la Internet Engineering Task Force, colaboración que culminó en 1999 con la publicación de una serie de RFC, siendo el más importante de ellos el RFC 2616 que especifica la versión 1.1. HTTP define la sintaxis y la semántica que utilizan los elementos de software de la arquitectura web (clientes, servidores, proxies) para comunicarse.

HTTP es un protocolo sin estado, por lo 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.

Descripción

Es un protocolo orientado a transacciones y sigue el esquema petición-respuesta entre un cliente y un servidor. El cliente (se le suele llamar "agente de usuario", del inglés user agent) realiza una petición enviando un mensaje, con cierto formato al servidor. El servidor (al que es común llamarle servidor web) le envía un mensaje de respuesta. Ejemplos de cliente son los navegadores web y las arañas web (también conocidas por su término inglés, webcrawlers).

Mensajes

Los mensajes HTTP son en texto plano, lo que lo hace más legible y fácil de depurar. Sin embargo, esto tiene el inconveniente de hacer los mensajes más largos. Los mensajes tienen la siguiente estructura:

 

Línea inicial (termina con retorno de carro y un salto de línea) con

Para las peticiones: la acción requerida por el servidor (método de petición) seguido de la URL del recurso y la versión HTTP que soporta el cliente.

Para respuestas: La versión del HTTP usado seguido del código de respuesta (que indica qué ha pasado con la petición seguido de la URL del recurso) y de la frase asociada a dicho retorno.

Las cabeceras del mensaje que terminan con una línea en blanco. Son metadatos. Estas cabeceras le dan gran flexibilidad al protocolo.

Cuerpo del mensaje. Es opcional. Su presencia depende de la línea anterior del mensaje y del tipo de recurso al que hace referencia la URL.

Métodos de petición

Un pedido HTTP usando telnet. El pedido (request), cabeceras de respuesta (response headers) y el cuerpo de la respuesta (response body) están resaltados.

 

HTTP define una serie predefinida de métodos de petición (algunas veces referido como "verbos") que pueden utilizarse. El protocolo tiene flexibilidad para ir añadiendo nuevos métodos y para así añadir nuevas funcionalidades. El número de métodos de petición se ha ido aumentando según se avanzaba en las versiones.1​ Esta lista incluye los métodos agregados por WebDAV.

 

Cada método indica la acción que desea que se efectúe sobre el recurso identificado. Lo que este recurso representa depende de la aplicación del servidor. Por ejemplo, el recurso puede corresponderse con un archivo que reside en el servidor.

 

GET

El método GET solicita una representación del recurso especificado. Las solicitudes que usan GET solo deben recuperar datos y no deben tener ningún otro efecto. (Esto también es cierto para algunos otros métodos HTTP.)

 

HEAD

RFC 2616. Pide una respuesta idéntica a la que correspondería a una petición GET, pero en la respuesta no se devuelve el cuerpo. Esto es útil para poder recuperar los metadatos de los encabezados de respuesta, sin tener que transportar todo el contenido.

 

POST

RFC 2616. Envía datos para que sean procesados por el recurso identificado en la URL de la línea petición. Los datos se incluirán en el cuerpo de la petición. A nivel semántico está orientado a crear un nuevo recurso, cuya naturaleza vendrá especificada por la cabecera Content-Type. Ejemplos:

 

Para datos formularios codificados como una URL (aunque viajan en el cuerpo de la petición, no en la URL): application/x-www-form-urlencoded

Para bloques a subir, ej. ficheros: multipart/form-data

Además de los anteriores, no hay un estándar obligatorio y también podría ser otros como text/plain, application/json, application/octet-stream,...

PUT

( RFC 2616 ) Envía datos al servidor, pero a diferencia del método POST la URI de la línea de petición no hace referencia al recurso que los procesará, sino que identifica al los propios datos (ver explicación detallada en el RFC). Otra diferencia con POST es semántica (ver REST): mientras que POST está orientado a la creación de nuevos contenidos, PUT está más orientado a la actualización de los mismos (aunque también podría crearlos).

 

Ejemplo:

 

PUT /path/filename.html HTTP/1.1

DELETE

RFC 2616. Borra el recurso especificado.

 

TRACE

( RFC 2616 ) Este método solicita al servidor que introduzca en la respuesta todos los datos que reciba en el mensaje de petición. Se utiliza con fines de depuración y diagnóstico ya que el cliente puede ver lo que llega al servidor y de esta forma ver todo lo que añaden al mensaje los servidores intermedios

 

OPTIONS

RFC 2616. Devuelve los métodos HTTP que el servidor soporta para un URL específico. Esto puede ser utilizado para comprobar la funcionalidad de un servidor web mediante petición en lugar de un recurso específico.

 

CONNECT

RFC 2616. Se utiliza para saber si se tiene acceso a un host, no necesariamente la petición llega al servidor, este método se utiliza principalmente para saber si un proxy nos da acceso a un host bajo condiciones especiales, como por ejemplo "corrientes" de datos bidireccionales encriptadas (como lo requiere SSL).

 

PATCH

( RFC 5789 ). Su función es la misma que PUT, el cual sobrescribe completamente un recurso. Se utiliza para actualizar, de manera parcial una o varias partes. Está orientado también para el uso con proxy.

Ejemplo de diálogo HTTP

Para obtener un recurso con el URL http://www.example.com/index.html

 

Se abre una conexión en el puerto 80 del host www.example.com. El puerto 80 es el puerto predefinido para HTTP. Si se quisiera utilizar el puerto XXXX habría que codificarlo en la URL de la forma http://www.example.com:XXXX/index.html

Se envía un mensaje en el estilo siguiente:

RFC 959

 

El Protocolo de transferencia de archivos (en inglés File Transfer Protocol o FTP)

Es un protocolo de red para la transferencia de archivos entre sistemas conectados a una red TCP (Transmission Control Protocol), basado en la arquitectura cliente-servidor. Desde un equipo cliente se puede conectar a un servidor para descargar archivos desde él o para enviarle archivos, independientemente del sistema operativo utilizado en cada equipo.

El servicio FTP es ofrecido por la capa de aplicación del modelo de capas de red TCP/IP al usuario, utilizando normalmente el puerto de red 20 y el 21. Un problema básico de FTP es que está pensado para ofrecer la máxima velocidad en la conexión, pero no la máxima seguridad, ya que todo el intercambio de información, desde el login y password del usuario en el servidor hasta la transferencia de cualquier archivo, se realiza en texto plano sin ningún tipo de cifrado, con lo que un posible atacante puede capturar este tráfico, acceder al servidor y/o apropiarse de los archivos transferidos.

Para solucionar este problema son de gran utilidad aplicaciones como SCP y SFTP, incluidas en el paquete SSH, que permiten transferir archivos pero cifrando todo el tráfico.

la siguiente modelo representa el diagrama de un servicio FTP

 

Ejemplos de Clientes FTPs

Entre los varios clientes FTP que existen, se pueden mencionar los siguientes:

 

·         net2ftp

·         WebDrive3​

·         Web-Ftp

·         Jambai FTP

·         ftp4net

·         PHP FTP Client

·         Asuk PHP FTP

·         Weeble File Manager

·         FileZilla4​

·         Transmit

 Comandos FTP

Códigos de respuesta de FTP

A continuación se muestra un resumen de la respuesta de los códigos FTP que puede ser devuelto por un servidor FTP. Estos códigos se han estandarizado en RFC 959 por IETF. El código de respuesta es un valor de tres dígitos. El primer dígito se utiliza para indicar una de tres posibles resultados-el éxito, el fracaso o para indicar un error o una respuesta incompleta:

 

 

·         2yz - respuesta Éxito

·         4yz o 5yz - No hay respuesta

·         1yz o 3yz - Un error o una respuesta incompleta

El segundo dígito define la clase de error:

 

·         x0z - Sintaxis. Estas respuestas se refieren a errores de sintaxis.

·         x1z - Información. Las respuestas a las solicitudes de información.

·         x2z - Conexiones. Respuestas en referencia al control y las conexiones de datos.

·         x3z - Autenticación y contabilidad. Respuestas para el proceso de inicio de sesión y los procedimientos contables.

·         x4z - No definido.

·         x5z - Sistema de archivos. Estas respuestas transmiten códigos de estado del sistema de archivos del servidor.

 

El tercer dígito del código de respuesta se utiliza para proporcionar detalles adicionales para cada una de las categorías definidas por el segundo dígito.

Conexión a un servidor FTP protegido desde navegador

Para iniciar sesión en un servidor FTP que requiere una contraseña teclee la URL de esta forma:

ftp://<usuario>:<contraseña>@<servidor ftp>/<url-ruta>

Donde <usuario> es el nombre de usuario, <servidor ftp> es el servidor FTP, <contraseña> es la contraseña de acceso, y <url-ruta> es el directorio donde iniciamos sesión.

Ejemplo: ftp://alumno:alumnopass@ftp.example.com/public

Modos de conexión del cliente FTP

FTP admite dos modos de conexión del cliente. Estos modos se denominan activo (o Estándar, o PORT, debido a que el cliente envía comandos tipo PORT al servidor por el canal de control al establecer la conexión) y pasivo (o PASV, porque en este caso envía comandos tipo PASV). Tanto en el modo Activo como en el modo Pasivo, el cliente establece una conexión con el servidor mediante el puerto 21, que establece el canal de control.

En modo Activo, el servidor siempre crea el canal de datos en su puerto 20, mientras que en el lado del cliente el canal de datos se asocia a un puerto aleatorio mayor que el 1024. Para ello, el cliente manda un comando PORT al servidor por el canal de control indicándole ese número de puerto, de manera que el servidor pueda abrirle una conexión de datos por donde se transferirán los archivos y los listados, en el puerto especificado.

Lo anterior tiene un grave problema de seguridad, y es que la máquina cliente debe estar dispuesta a aceptar cualquier conexión de entrada en un puerto superior al 1024, con los problemas que ello implica si tenemos el equipo conectado a una red insegura como Internet. De hecho, los cortafuegos que se instalen en el equipo para evitar ataques seguramente rechazarán esas conexiones aleatorias. Para solucionar esto se desarrolló el modo pasivo. Aunque realmente no es así ya que seguramente la seguridad tendrá un problema grave.

Modo pasivo.

Cuando el cliente envía un comando PASV sobre el canal de control, el servidor FTP le indica por el canal de control, el puerto (mayor a 1024 del servidor. Ejemplo:2040) al que debe conectarse el cliente. El cliente inicia una conexión desde el puerto siguiente al puerto de control (Ejemplo: 1036) hacia el puerto del servidor especificado anteriormente (Ejemplo: 2040).⁵​

Antes de cada nueva transferencia tanto en el modo Activo como en el Pasivo, el cliente debe enviar otra vez un comando de control (PORT o PASV, según el modo en el que haya conectado), y el servidor recibirá esa conexión de datos en un nuevo puerto (aleatorio si es en modo pasivo o por el puerto 20 si es en modo activo).

Tipos de transferencia de archivos en FTP

En el protocolo FTP existen 2 tipos de transferencia en ASCII y en binarios. Es importante conocer cómo debemos transportar un archivo a lo largo de la red, si no utilizamos las opciones adecuadas podemos destruir la información del archivo. Por eso, al ejecutar la aplicación FTP, debemos acordarnos de utilizar uno de estos comandos (o poner la correspondiente opción en un programa con interfaz gráfica):

Tipo ASCII

Adecuado para transferir archivos que solo contengan caracteres imprimibles (archivos ASCII, no archivos resultantes de un procesador de texto), por ejemplo páginas HTML, pero no las imágenes que puedan contener. Se transforman algunos símbolos de control para mantenerlos compatibles entre diferentes sistemas, por ejemplo, si el archivo está alojado sobre un servidor linux, el salto de línea para los archivos de texto es "\n" (byte 10 en decimal). Si el cliente es un sistema Mac, el salto de línea es "\r" (byte 13 en decimal), este modo cambia estos símbolos de control para que el archivo sea legible en ambos lados, al igual que si se envía a un sistema windows, el salto de línea es "\r\n" (dos bytes, 13 y 10). Si se usa este modo en archivos que no son de texto plano, en el caso de intercambiarse entre diferentes sistemas, ese archivo quedará corrupto.

Tipo Binario

Este tipo es usado cuando se trata de archivos comprimidos, ejecutables para PC, imágenes, archivos de audio, entre otros.

Ejemplos de cómo transferir algunos tipos de archivo dependiendo de su extensión:

RFC 5321

Protocolo para transferencia simple de correo

El Protocolo Simple de Transferencia de Correo (en inglés: Simple Mail Transfer Protocol o SMTP) es un protocolo de red utilizado para el intercambio de mensajes de correo electrónico entre computadoras u otros dispositivos (PDA, teléfonos móviles, impresoras, etc.). Se encuentra en la capa de aplicación del modelo OSI1​, la última de este modelo, en la que se dispone la interfaz entre las aplicaciones de comunicación y la red que transmite los mensajes2​. Fue definido inicialmente en agosto de 1982 por el RFC 821 (para la transferencia) y el RFC 822 (para el mensaje), dos estándares oficiales de Internet que fueron reemplazados respectivamente por el RFC 2821 y el RFC 2822, posteriormente destituidos por los estándares RFC 5321 y RFC 5322.3​

 

El funcionamiento de este protocolo se da en línea, de manera que opera en los servicios de correo electrónico. Sin embargo, posee algunas limitaciones en cuanto a la recepción de mensajes en el servidor de destino (cola de mensajes recibidos), por lo que se ejecuta normalmente en relación con otros, como POP3 o IMAP, otorgando a SMTP la tarea específica de enviar correos y delegando la de recibirlos a los protocolos antes mencionados.

Modelo de procesamiento del correo.

El correo electrónico es presentado por un cliente de correo (MUA, agente de usuario de correo) a un servidor de correo (MSA, agente de sumisión de correo) usando SMTP a través del puerto 587. Una gran parte de los proveedores de correo todavía permiten el envío a través del puerto 25. Desde allí, el MSA entrega el correo a su agente de transferencia postal mejor conocido como el MTA (Mail Transfer Agent, Agente de Transferencia de Correo). En algunas ocasiones, estos dos agentes son casos diferentes aunque hay que destacar que provienen del mismo software de donde fueron lanzados sólo que presentan opciones diferentes dentro de la misma máquina.

Puertos

Los administradores de servidor pueden elegir si los clientes utilizan TCP puerto 25 (SMTP) o el puerto 587 (Presentación) para retransmitir el correo saliente a una inicial del servidor de correo.4​ Las especificaciones y muchos servidores soportan ambos. Aunque algunos servidores soportan el puerto 465 para el legado SMTP seguro en violación de las especificaciones, es preferible utilizar los puertos estándar y comandos SMTP estándar de acuerdo con RFC 3207, si se debe utilizar una sesión segura entre el cliente y el servidor.

 

 

Descripción del Protocolo

SMTP. Una transacción de SMTP se compone de tres secuencias de comando / respuesta (véase el ejemplo a continuación).

 

Ellos son:

·         MAIL FROM: comando para establecer la dirección de retorno, también conocido como Return-Path, remitente o sobre. Esta es la dirección para mensajes de despedida.

·         RCPT TO: comando, para establecer un destinatario de este mensaje. Este mandato puede emitirse varias veces, una para cada destinatario. Estas direcciones son también parte de la envolvente.

·         DATA: para enviar el mensaje de texto. Este es el contenido del mensaje, en lugar de su envoltura. Se compone de una cabecera de mensaje y el cuerpo del mensaje separado por una línea en blanco. DATA es en realidad un grupo de comandos, y el servidor responde dos veces: una vez para el comando de datos adecuada, para reconocer que está listo para recibir el texto, y la segunda vez después de la secuencia final de los datos, para aceptar o rechazar todo el mensaje.

 

Resumen simple del funcionamiento del protocolo SMTP

·         Cuando un cliente establece una conexión con el servidor SMTP, espera a que este envíe un mensaje “220 Service ready” o “421 Service non available”.

·         Se envía un HELO desde el cliente. Con ello el servidor se identifica. Esto puede usarse para comprobar si se conectó con el servidor SMTP correcto.

·         El cliente comienza la transacción del correo con la orden MAIL FROM. Como argumento de esta orden se puede pasar la dirección de correo al que el servidor notificará cualquier fallo en el envío del correo (Por ejemplo, MAIL FROM:<fuente@host0>). Luego si el servidor comprueba que el origen es válido, el servidor responde “250 OK”.

·         Ya le hemos dicho al servidor que queremos mandar un correo, ahora hay que comunicarle a quien. La orden para esto es RCPT TO:<destino@host>. Se pueden mandar tantas órdenes RCPT como destinatarios del correo queramos. Por cada destinatario, el servidor contestará “250 OK” o bien “550 No such user here”, si no encuentra al destinatario.

·         Una vez enviados todos los RCPT, el cliente envía una orden DATA para indicar que a continuación se envían los contenidos del mensaje. El servidor responde “354 Start mail input, end with <CRLF>.<CRLF>” Esto indica al cliente como ha de notificar el fin del mensaje.

·         Ahora el cliente envía el cuerpo del mensaje, línea a línea. Una vez finalizado, se termina con un <CRLF>.<CRLF> (la última línea será un punto), a lo que el servidor contestará “250 OK”, o un mensaje de error apropiado.

·         Tras el envío, el cliente, si no tiene que enviar más correos, con la orden QUIT corta la conexión. También puede usar la orden TURN, con lo que el cliente pasa a ser el servidor, y el servidor se convierte en cliente. Finalmente, si tiene más mensajes que enviar, repite el proceso hasta completarlos.

Puede que el servidor SMTP soporte las extensiones definidas en el RFC 1651, en este caso, la orden HELO puede ser sustituida por la orden EHLO, con lo que el servidor contestará con una lista de las extensiones admitidas. Si el servidor no soporta las extensiones, contestará con un mensaje "500 Syntax error, command unrecognized".

 

Comandos

·         HELO, para abrir una sesión con el servidor

·         EHLO, para abrir una sesión, en el caso de que el servidor soporte extensiones definidas en el RFC 1651

·         MAIL FROM, para indicar quien envía el mensaje

·         RCPT TO, para indicar el destinatario del mensaje

·         DATA, para indicar el comienzo del mensaje, este finalizará cuando haya una línea únicamente con un punto.

·         QUIT, para cerrar la sesión

·         RSET Aborta la transacción en curso y borra todos los registros.

·         SEND Inicia una transacción en la cual el mensaje se entrega a una terminal.

·         SOML El mensaje se entrega a un terminal o a un buzón.

·         SAML El mensaje se entrega a un terminal y a un buzón.

·         VRFY Solicita al servidor la verificación de todo un argumento.

·         EXPN Solicita al servidor la confirmación del argumento.

·         HELP Permite solicitar información sobre un comando.

·         NOOP No decir nada, se emplea para mantener la sesión abierta

·         TURN Solicita al servidor que intercambien los papeles.

·         De los tres dígitos del código numérico, el primero indica la categoría de la respuesta, estando definidas las siguientes categorías:

 

·         2XX, la operación solicitada mediante el comando anterior ha sido concluida con éxito

·         3XX, la orden ha sido aceptada, pero el servidor está pendiente de que el cliente le envíe nuevos datos para terminar la operación

·         4XX, para una respuesta de error, pero se espera a que se repita la instrucción

·         5XX, para indicar una condición de error permanente, por lo que no debe repetirse la orden

·         Una vez que el servidor recibe el mensaje finalizado con un punto puede almacenarlo si es para un destinatario que pertenece a su dominio, o bien retransmitirlo a otro servidor para que finalmente llegue a un servidor del dominio del receptor.

 

Ejemplo de una comunicación SMTP

En primer lugar se ha de establecer una conexión entre el emisor (cliente) y el receptor (servidor). Esto puede hacerse automáticamente con un programa cliente de correo o mediante un cliente telnet.

En el siguiente ejemplo se muestra una conexión típica. Se nombra con la letra C al cliente y con S al servidor.

 

Seguridad y spam

Artículo principal: Antispam

Una de las limitaciones del SMTP original es que no facilita métodos de autenticación a los emisores, así que se definió la extensión SMTP-AUTH en RFC 2554.

A pesar de esto, el spam es aún el mayor problema. No se cree que las extensiones sean una forma práctica para prevenirlo. Internet Mail 2000 es una de las propuestas para reemplazarlo.[cita requerida]

Diferentes metodologías han aparecido para combatir el spam. Entre ellas destacan DKIM, Sender Policy Framework (SPF) y desde 2012 Domain-based Message Authentication, Reporting and Conformance (DMARC).6​