4. Protocols d'aplicació

Forum Pàgina Inicial

4.1. Noms de domini

4.1.1. Domain Name System (DNS)

4.2. Accés remot i tranferència de fitxers

4.2.1. Telnet i Comandes R
4.2.2. Secure SHell (SSH) i Secure CoPy (SCP)
4.2.3. File Transfer Protocol (FTP)

4.3. Correu electrònic i Web

4.3.1. Simple Mail Transfer Protocol (SMTP)
4.3.2. Hyper Text Transfer Protocol (HTTP)

4.4. Video i veu sobre IP

4.4.1. Real Time Protocol (RTP)
4.4.2. Veu sobre IP (VoIP)

4.5. Gestió de Xarxes

4.5.1. Simple Network Management Protocol (SNMP)

4.6. Inicialització i autoconfiguració

4.6.1. Bootstrap Protocol (BOOTP)
4.6.2. Dynamic Host Configuration Protocol

4.1. NOMS DE DOMINI

4.1.1. DOMAIN NAME SYSTEM (DNS)

()

El Domain Name System (DNS) es una base de datos distribuida y jerárquica que guarda información asociada a nombres de dominio en redes, cuyo uso más común es la asignación de nombres de dominio a direcciones IP y la localización de los servidores de correo electrónico de cada dominio.

Existen diferentes requisitos en Internet:

Protocolos :
- Uso de direcciones IP de 32 bits.
- Low-level names.
- Direcciones difíciles de recordar para los seres humanos.
Usuarios :
- Uso de nombres pronunciables y fácilmente recordables.
- High-level names.

Por esto se hace necesario poder hacer un Mapping entre los Low-level names y los High-level names, que además de ser más fáciles de recordar, permiten que el low-level name (dirección IP) cambie sin que tenga que cambiar el nombre.

En sus inicios el DNS nació de la necesidad de recordar fácilmente los nombres de todos los servidores conectados a Internet. así que "SRI Internacional" guardaba un archivo llamado HOSTS que contenía todos los nombres de dominio conocidos, este archivo aún existe.

El crecimiento de la red hizo que este archivo centralizado de HOSTS no resultara práctico y en 1983, Paul Mockapetris publicó los RFCs 882 y 883 definiendo el DNS. (Últimos RFCs 1034 y 1035).

Para hacer el mapping hará falta:

Mecanismo para hacer las asignaciones de los nombres.
Servicio distribuído de traducciones de los nombres.

Como ya se ha comentado, estos servicios son proporcionados por el Domain Name System (DNS), que gracias a una estructura jerárquica soluciona los problemas técnicos y administrativos que presentaba el esquema plano del archivo de HOSTS. Además la partición del espacio permite un control autónomo y un mapeo eficiente.

A partir de ahora ya no hablaremos de nombres, sinó de dominios, que utilizan un esquema aproximado al little-endian :

?DominioLocal[...].?DominioSecundario.?DomnioPrimario

Dominio Primario : Nombre del lugar autorizado por la autoridad central.
Dominio Secundario : Nombre autorizado por la autoridad del primario.
Dominio Local o Final : Parte del nombre controlada por el administrador del penúltimo dominio.

En Internet los nombres se asignan según la estructura de la organización que obtiene la autorización de una parte del espacio de nombres, que no tiene que corresponder necesariamente con la estructura de las redes físicas.

Así por ejemplo en el nombre deic.uab.es :

"es" es un dominio primario.
"uab" es un dominio secundario.
"deic" es un dominio local.
"deic.uab.es" tan¡mbién es un dominio.
"uab.es" tan¡mbién es un dominio.

El estándard definico permite que se pueda uasr cualquier nombre en cualquiera de los niveles, aunque lo normal es utilizar el sistema de nombres oficial de internet. Hay diferentes clasificaciones de los dominios primarios :

Según para que tipo de ORGANIZACIÓN :
- COM : para Organizaciones Comerciales.
- EDU : para Instituciones Educativas.
- GOV : para Instituciones Gubernamentales.
- NET : para Centros de Soporte en la red.
- ORG : para el resto de organizaciones.
Según su locaclización GEOGRÁFICA :
- ES : España.
- AR : Argentina.
- IT : Italia.

ESTRUCTURA DE ÁRBOL :

La relación existente entre los nombres de dominio y las direcciones no es biyectiva, ya que pueden existir dominios asociados a más de una dirección, y vicerversa, direcciones asociadas a más de un dominio, así como pueden existir dominios sin dirección y direcciones sin dominio. Hay que tener muy claro que sólo a partir del nombre de un dominio no podemos saber si existe un subdominio, por ejemplo uab.es puede ser un subdominio, pero también puede ser el nombre de una máquina, o puede ser las dos cosas, ...

Las características del sistema de DNS son :

Distribuido : el trabajo de solución del mapeado es realizado por diferentes servidores que cooperan desde diferentes lugares.
Eficiente : no se carga la red de demasiado tráfico ya que la mayor parte de los nombres se resuelven localmente.
Fiable : el sistema es inmune al fallo de alguna de las máquinas donde haya un servidor, el resto continúan funcionando correctamente.
De Propósito General : puede guardar otro tipo de información, no se limita únicamente a la resolución de nombres de máquinas.

CONSULTAS AL DNS

Existe un servidor asociado a cada dominio no local que permite resolver las peticiones de los clientes, así una petición de traducción de nombre por parte de un cliente sigue los siguientes pasos:

El cliente tiene que poder y saber contactar con al menos uno de dichos servidores de DNS.

El cliente hace su petición de resolución del nombre deseado, la clase de dicho nombre, el tipo de respuesta que espera y un código que especifica la manera de resolverlo, que puede ser :

ITERATIVA	Si el servidor contactado por el usuario no puede resolver el nombre, le indica al cliente otro servidor con ql que ponerse en contacto para solucionar dicho nombre.
RECURSIVA	Si el servidor contactado por el usuario no puede resolver el nombre, éste mismo servidor se pone en contacto con otro servidor hasta poder resolver el nomre y responder al cliente

El servidor intentará resolver la petición del cliente y una vez resuelta le enviará el resultado.

Para que todo este sistema funcione correctamente existen dos condiciones neecsarias:

El puerto de prtotocolo utilizado por el DNS es un puerto muy bien conocido por todas las clomunicaciones tanto TCP como UDP, el puerto 53.
Cada servidor de un dominio ha de conocer la dirección de al menos un servidor de su sominio inmediatamente superior.

Mediante una técnica de caching se consigue mejorar la eficiencia del sistema :

Los servidores mantienen una caché que almacena las peticiones recientes recibidas y un registro del servidor que ha proporcionado la información.
Existe un tiempo de caducidad de las enrtadas en esta tabla, que puede ser un tiempo fijo o un TTL devuelto por una autoridad en la respuesta a una petición.

TIPOS DE OBJETOS Y CONTENIDOS DE LOS REGISTROS DE RECURSOS

TIPO	CONTENIDO	DESCRIPCIÓN
A	Dirección	Dirección IP de 32 bits
CNAME	Nombre Canónico	Nombre canócico para un alias
HINFO	CPU & OS	Tipo de máquina y sistema operativo
MX	Mail Exchanger	Quien recibe el mail del dominio
NS	Servidor de los nombres	Servidor con autoridad
PTR	Punter	Nombre del dominio
SOA	Start Of Authority	Comienzo del dominio
TXT	Text	Cadena ASCII de texto

COMANDO PARA UTILIZAR EL SERVICIO DE DNS

EJEMPLO :

Fuentes y más información:

http://en.wikipedia.org/wiki/Domain_name_system
http://es.wikipedia.org/wiki/Domain_Name_System
http://www.ietf.org/rfc/rfc1034.txt
http://www.ietf.org/rfc/rfc1035.txt
http://www.dns.net/
http://www.dcc.uchile.cl/~jpiquer/Internet/DNS/node2.html
Apuntes de clase

Índex

(DavidSánchez)[08/01]

Història de les assignacions de noms i adreces

$/!\$ Segons les webs que he consultat per per aquest apartat d'historia, les dates ballen força, es a dir, que el mateix fet que en la trasparència de teoria diu una data, per exemple en wikipedia en diu una altra, próximes entre si però diferents.

Com bé es veu en aquest diagrama de temps, aquest diagrama esta dividit en dues parts diferenciades, una per al registre i publicació de noms i adreces, i l'altra per a la corordinació dels valors dels protocols. En el llindar dels dos grups hi ha una franja en la que ens diu que en 1967 (1969 en wikipedia) DARPA (Doug Engelbart) comença la planificació (crea) d'una xarxa d'ordenadors que permetís comunicar els humans davant una possible guerra nueclear que inutilitcés les comunicacions existents per la època. Aquesta xarxa tenia un caràcter de defensa. L'any 1971,Peggy Karp, crea el concepte de Noms d'internet construint la primera taula de noms de hosts. Durant el 1972 hi va haber la primera demostració pública de ARPANET, que va ser la primera xarxa de comunicacions financiada per DARPA i que funcionaba de forma distribuïda sobre una xarxa telefònica commutada. A més a més, aquest any apareix la primera taula de noms de hosts distribuïda. En 1977, Postel inicia un protocol d'assignació de nombres i adreçes (ISI). En 1981, Apareix per la ment de Dave Mills el concepte (idea) de Domini. El primer dia de l'any 1983, ARPANET canvia el pritocol NCP pel TCP/IP. Aquest mateix any es crea el IAB amb l'obejctiu d'estandaritzar el protocol TCP/IP i donar un recurs d'investigació a Internet. Per una altra banda, aquest mateix any la IANA se centra en l'assignació d'identificadors, que més tard, va delegar a Internet Registry que a la vegada proporcionaba servei de DNS el qual es va iniciar el 1985. Aquest mateix any, la Universitat Global de Londres (UCL), crea el NIC UK per als DNS. En 1992, ja hi habia 31 paisos amb NIC, en 1993, el nombre pujaba a 51 i la progressió augmenta fins el 1998 en els quals hi han 242 paisos amb NIC propi.
En 1987 es comença a assignar l'adreça IP en al trasferencia i el 1991 DISA NIC es traferit a GSI que aqust DISA NIC en 1997 va ser transferit a Boeing.
En 1993, algunes funcions del NIC són tranferides a NSI via NFC/NSF on en 1998, tan COM, ORG, EDU i NET passen a ser NSI.

Fonts:
Apunts de Classe
http://es.wikipedia.org/wiki/Internet
http://www.scit.wlv.ac.uk/~jphb/comms/dns.html

Índex

4.2. ACCÉS REMOT I TRANFERÈNCIA DE FITXERS

4.2.1. TELNET I COMANDES R

(DavidSánchez)[08/01]

Telnet

Telnet és el nom d'un protocol d'ús interactiu de màquines remotes, es a dir, serveix per accedir per mitjà d'una xarxa a una màquina con si estiguèssim davant d'aquesta. Això significa que que s'ha d'obrir una sessió en aquesta màquin a la que volem accedir per poder executar certes comandes. Per a que funcioni la conexió les màquines implicades han de tenir una aplicació Client/Servidor, es a dir, han de tenir una aplicació/un programa d'aquest tipus per a iniciar, gestionar i finalitzar la sessió.
El protocol telnet utilitza connexions TCP per enviar quines són les tecles polsades en el teclat de l'usuari cap a la màquina remota. Els resultats de la màquina remota son enviats (retornats) directament a la pantalla de l'usuari, donant una sensació de que tan el teclat com la pantalla de la màquina client (la màquina que utilitza l'usuari) estigui connectat directament a la màquina servidora (la màquina remota).El port que s'utilitza en aquesta connexió és el Port 23.

Telnet ens ofereix una xarxa virtual que ens proporciona una interfície estàndard al sistema remot i independent d'aquest al qual solament es pot accedir en mode terminal, es a dir, mitjançant una "finestra" en la que hi escriurem amb el teclat les comandes en mode text i sense gràfics (com mostren en la imatge anterior).
Telnet ens ofereix un mecanisme que permet al client (màquina de l'usuari) i al servidor (màquina remota), de forma simètrica, negociar opcions (cada extrem de la conexió pot negociar, es a dir, dona la possibilitat que tan un com l'altre inicïi la negociació amb l'objectiu de reconfigurar la connexió), per tant es defineix un conjunt estàndard d'opcions.

Nota: Per a més informació respecte Telnet mirar l'ampliació que jo mateix he fet.

Índex

Comandes R*

Les comandes R* són tres comandes que forment part exclusivament d'entorns Unix que serveixen per gestionar un ordenador de forma remota. Aquestes comandes són les següents:
rlogin(Remote login per hosts autoritzats): Comanda que s'utilitza quan hi ha un conjunt de màquines les quals comparteixen noms d'entrada. El que succeeix és que d'una màquina auna altra d'aquest grup sense haber d'entrar cada vegada la paraula de pas, es a dir, que aquestes màquines tene autorització automàtica. Aquesta comanda té un caràcter similar al telnet.
rsh(Remote shell per hosts autoritzats): Crea un terminal (invoca l'interpret de comandes) del sistema remot i li passa una comanda en mode text, es a dir, una comanda de linia, sense haber de identificar-se.
rcp(Remote copy per hosts autoritzats): Copia fitxers entre comptes de màquines autoritzades sense cap demanda de indentificació.

Aquest mètode de gestionament remot (telnet, ComandesR)genera força inconvenients ja que les aplicacions que les utilitzen, són molt insegures, ja que en el telnet l'autenticació es trasmet en clar i el les comandes R* es basa en una adreça IP. Un altre inconvenient d'aquests mètodes de gestió és la facilitat amb la que es pot interceptar la informació que travessa una xarxa, per exepmple Ethernet o bé fer IP-Spoofing. Per aquest motius es recomana la nul.la utilització d'aplicacions que utilitzen aquests mètodes de gestió en entorns públics.
La evolució d'aquestes aplicacions són el SSH i el SCP, que seguidament explicarem.

Fonts:
Apunts de Classe
http://es.wikipedia.org/wiki/Telnet
http://es.wikipedia.org/wiki/R-commands

Índex

4.2.2. SECURE SHELL (SSH) i SECURE COPY (SCP)

(DavidSánchez)[10/01]

Secure Shell (SSH)

Secure Shell (SSH) és el nom que rep el protocol o el programa el qual implementa a aquest protocol, que serveix per accedir a màquinari (ordenadors) de forma remota mitjançant una xarxa i el port reservat 22. Un exemple de conexió remota amb execució de comandes remotes és el que s'ens mostra en una trasparència de teoria.

Exemple connexió remota

# ssh montse@deic-laptop12.uab.es
# Enter passphrase for key ’/home/montse/.ssh/id_dsa’:
Last login: Wed Oct 6 15:31:55 2004
#

Exemple execució remota

# ssh montse@deic-laptop12.uab.es w
# Enter passphrase for key ’/home/montse/.ssh/id_dsa’:
1:27pm up 18:40, 1 users, load average: 0.00,0.00,0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
montse pts/0 :0 11:49am 2.00s 15.52s 0.24s bash
#

El que permet SSH és el manejament total de la màquina remota, mitjançant un intèrpret (antigament solament s'utilitzaba amb linia de comandes), però a diferencia de telnet i de les comandes R*, de forma segura.
Pel que fa referencia a la seguritat de les dades de la comunicació entre màquines, SSH treballa de forma semblant a telnet però amb la diferencia que SSH utilitza unes tècniques de xifrat de les dades que fan que aquestes viatgin de forma ilegible i no pugui ser desxifrada en mig de la comunicació, encara que que es pot atacar aquest model de seguretat per mitjà d' atacs de REPLAY. Per a aquest intercanvi privat i autèntic de la informació el protocol utilitza un SSL (Secure Socket Layer). Cada host té tan una clau pública com una privada amb les quals es defineixen relacions de confiança.
Per tant, els usuaris del SSH podran utentificar-se de forma segura a través de la forma habitual, es a dir, de la paraula de pas habitual, paraula que pasarà per dins del túnel xifrat (SSL), o bé també es podrà autentificar per mitjà d'un esquema de claus aritmètiques.

Índex

Secure Copy (SCP)

Secure Shell (SSH) és el nom que rep el protocol o el programa el qual implementa a aquest protocol que serveix per transferir arxius d'un hots a un altre de remot. Aquest protocol és de la familia SSH, ja que per exemple SCP utilitza el túnel SSL i el port reservat 22 com fa SSH.
Les dades d'aquest protocol són encriptades durant la seva trasferència per evitar que d'aquets paquets de dades que s'envien els sniffers de paquets puguin extreure informació útil. Per contrapartida no proporciona autentificació, ja que espera que el propi SSH s'encarregui de la seguretat.

Exemple copia segura

# scp montse@deic-laptop12.uab.es:fitxer /tmp
# Enter passphrase for key ’/home/montse/.ssh/id_dsa’:
fitxer 100\% |***********************| 11899 00:00
#
# scp /etc/hosts root@deic-dc1:/etc
# Enter passphrase for key ’/home/montse/.ssh/id_dsa’:
hosts 100\% |************************| 434 00:00

Fonts:
Apunts de Classe
http://es.wikipedia.org/wiki/SSH
http://es.wikipedia.org/wiki/SCP

Índex

4.2.3. FILE TRANSFER PROTOCOL (FTP)

(DavidSánchez)[10/01]

És un dels diferents protocols de transferencia de dades (File Transfer Protocol) que s'utilitza en Internet acutal. Es ideal per transferir grans blocs de dades. A més a més proporciona les facilitats següents, juntament amb la mencionada de la transferència de dades:
Proporciona un accès interactiui concurrent, es a dir, hi ha implementacions que permenten una interacció, d'usuaris-servidors remots, fàcil. Pel que fa la concurrencia, significa que els clients del protocol poden accedir al servidor simultàniament.
Per tenir un control d'aquest accés, hi ha un control d'autenticació, es a dir, s'ha de trasmetre un nom d'usuari i un possawprd per poder tenir accés al servidor.
Una altra facilitat que FTP proporciona a l'usuari es la especificació de format, es a dir, que FTP permet al client especificar la representació i el tipus de les dades emmagatzemades en el servidor.

Per transportar les dades i la informació s'utilitza el protocol TCP per canals separats, amb els ports reservats 20 i 21, on el port 20 s'utilitza per al fluxe de dades entre client-servidor i el port 21 (Well-Known) per al fluxe de control (ordres del client al servidor). Per aquest 'ultim tipus de connexió, la de control, en el client, que es qui sera qui la iniciarà, el port utilitzat per a la connezió és aleatori i assignat localment.

Pel que fa referència a la transferència el client utilitzarà dos modes diferents, actiu i passiu, els quals determinaran quins ports (per part del client) i qui iniciarà, servidor o client, en la connexió de dades. Pel que fa la connexió en mode actiu el port que usa el servidor és el 20, com bé hem dit abans i per a cada trasferència el client ha d'obtenir un port per a la creació d'un procés de transferència la qual espera per aquest port. És el client qui, per mitjà de la connexió de control, envia el número de port utilitzat per a la connexió de dades al sevirdor i aquest, mentre el client espera, com bé hem dit abans, estableix la connexió TCP als ports utilitzats per a la connexió de dades. La cordinació d'aquest procés entre client i el servidor es realitza per mitjà de l’assignació dinàmica de ports de protocol i per la creació de processos de transferència de dades que fan servir aquests ports.
Com a apunts interessants, la majoria de pàgines web a nivell mundial, són pujades al servidor corresponent mitjançant aquest protocol utilitzat mitjançant un navegador web (també es pot utilitzar programes especials o mitjançant linia de comandes) mitjançant una direcció del tipus http://usuari:contrasenya@servidor.

Fonts:
Apunts de Classe
http://es.wikipedia.org/wiki/File_Transfer_Protocol
http://www.vc.ehu.es/wuagacaj/manual/ftp/ftp.html

()[15/01]

En el mode passiu es el servidor el que ha d'escollir un port local i obrir-lo per acceptar connexions. Una vegada es disposa d'aquest port, en el següent pas se li enviarà el port al client a través de la sessió de control. Finalment el client farà la petició de connexió al port del servidor, amb lo que la sessió de dades quedarà oberta. Per activar el mode passiu cal especificar la comanda PASV.
La necessitat d'enviar el nombre de port ha suposat certs problemes a tecnologies com NAT, que han hagut d'adaptar-se adequadament. El mode passiu aconsegueix resoldre en part el problema, però provoca uns altres com per exemple amb els firewalls. En el cas del client que poden estar configurats per permetre connexió només a well-know-ports, i en el cast del servidor poden estar-ho per acceptar connexions a uns ports determinats.

Es mostra com a exemple una sessió FTP en mode actiu en la qual es transfereix el llistat de fitxers d'un directori.

Fonts:

Apunts de la assignatura
http://www.ncftp.com/ncftpd/doc/misc/ftp_and_firewalls.html
http://en.wikipedia.org/wiki/FTP
http://www.isaserver.org/articles/How_the_FTP_protocol_Challenges_Firewall_Security.html

Índex

4.3. CORREU ELECTRÒNIC I WEB

4.3.1. SIMPLE MAIL TRANSFER PROTOCOL (SMTP)

()[15/01]

Estàndard de facto per l'enviament de correu electrònic. La primera aparició en forma de RFC data del 1982, concretament al RFC821. El port associat es el 25.
Un dels seus pilars es la simplicitat, per això es bastant senzill fer probes directament amb un client de telnet. El protocol només s'ocupa de definir un sistema per tal de lliurar els missatges d'un ordinador a un altre, però no de quan s'envien, com s'accepten, com s'emmagatzemen o com es presenten els correus a l'usuari.
- Lliurament de correu (delayed delivery)
  Opera en tres passos:
  - Creació d'un agent per atendre a les peticions del client de correu
  - Cua per emmagatzema cada missatge format per dues parts: text del missatge i llista de destinataris
  - Transmissió a través de diverses connexions TCP al port 25 de cada destinatari

Lliurament per el client

1	Trobar la direcció de destí (DNS)
2	Establement de connexió
3	Enviament i emmagatzemament a l'àrea de spool del servidor
4	Cerca del proper destinatari, si no hi ha mes esborrar el missatge de la cua d'enviament

Recepció per el servidor
- 1
  
  Acceptar el missatge
  
  1a
  
  Posar a la bústia del destinatari
  
  1b
  
  Posar a la cua si cal reenviar
  
  2
  
  Verificar els destinataris
  
  3
  
  Comprovar errors
  - Es per això que no es pot comprovar si s'ha enviat correctament, el protocol al costat del client termina en quant s'ha fer l'enviament.

Funcionament del protocol

Protocol senzill d'enviament de comandes i respostes en format de text ASCII.

Comandes

Línia de text que comença amb una de les comandes disponibles. No son sensibles a majúscules (case insensitive)

Comandes definides inicialment al RFC821.

HELO	Inicialització de les comunicacions
MAIL	Identitat del remitent del correu
RCPT	Definir les direcció a on s'enviarà el correu. Cada vegada que s'executi s'afegeix un destinatari
DATA	Cos del missatge. Aquest s'enviarà realitzant una vegada comanda i introduint línia per línia el missatge. A aquesta comanda es posa fi amb una línia que contingui només un punt ('.')
SEND	Realitzar l'enviament. Si no es possible retorna un missatge d'error
SOML	Igual que l'anterior, en aquest cas l'error s'emmagatzema en el mailbox del remitent
SAML	Realitza l'enviament i guarda el correu al mailbox en qualsevol cas
RSET	Abortar enviament
VRFY	Comprova que existeix el usuari en el servidor especificat a la direcció d'enviament
EXPN	Igual que l'anterior però per llistes de correu
HELP	Demana informació sobre una comanda
NOOP	No operació
QUIT	S'autoritza el receptor a tancar la connexió TCP
TURN	Serveix per intercanviar el rols entre client i servidor

Respostes

Línia amb el codi de la resposta i opcionalment un text explicatiu. Codi de les respostes mes comuns:

214	Ajut sobre una comanda
220	Syn-ACK
221	Tancada la connexió
250	Resposta de confirmació
354	Confirmació parcial positiva
500	Error sintàctic
502	Comanda no implementada
503	Seqüència incorrecta de comandes
552	Acció abortada per no disposar de mes quota de disc
553	Mailbox incorrecte
554	Error en la transacció

Fases
- Establiment connexió
  - Es fa la connexió i s'envia la comanda HELO host
- Transmissió del missatge
  - S'han d'utilitzar obligatoriament i en ordre les comandes: MAIL, RCPT i DATA.
- Tancament de la connexió
  - S'envia la comanda de finalització QUIT. El servidor comprobarà les dades i enviarà el correu.
Exemple d'enviament

Servidor/Client	Enviament
S	220 www.example.com ESMTP Postfix
C	HELO www.mydomain.com
S	250 Hello www.mydomain.com
C	MAIL FROM:sender@mydomain.com
S	250 Ok
C	RCPT TO:friend@example.com
S	250 Ok
C	DATA
S	354 End data with {<CR><LF>.<CR><LF>}
C	Subject: test message
C	From:sender@mydomain.com
C	To:friend@example.com
C
C	Hello,
C	This is a test.
C	Goodbye.
C	.
S	250 Ok: queued as 12345
C	QUIT
S	221 Bye

Fonts:

Apunts de la assignatura
http://en.wikipedia.org/wiki/SMTP
http://tools.ietf.org/html/rfc821

L'adreça de correu electronic
()[15/1]

L'adreça de correu electrònic te un format molt característic que ens dona força informació amb un cop d'ull.
El primer tret característic és el simbol @. Aquest símbol es pronuncia "AT" en Anglès ("A" en Català) i serveix per determinar a on es troba una adreça determinada.
Per tant quan llegim @gmail.com podem interpretar-ho com a " a gmail.com"

Com podem veure en aquest esquema la paraula abans de l'arroba en realitat identifica una bustia concreta dins d'un domini. Per altra banda, el que hi ha després de l'arroba és el nom de domini que identificarà una màquina de destí o un MX MAIL EXCHANGER de DNS.

NOTA: Per raons obves el nom de la bustia (que va abans de l'arroba) no pot contenir caràcters "@"

Re-encaminament del correu electronic

En el cas de que volguem crear una llista de distribució o simplement redireccionar els e-mails van a una conta a una altra conta cal que els servidors SMTP parlin entre si per a intercanviar missatges.

Aquest procedimen es el que anomenem "Mail Forwarding". Els correus electronics s'intercanvien entre els diferents Mail Exchangers fins que arriben al mail exchanger del destinatari/destinataris. Un exemple el trobem aquí:

També pot passar que es vulgui enviar un e-mail a un usuari que no utilitza el protocol SMTP. En aquest cas també s'utilizarà el re-encaminament de correu electrònic però per a convertir els missatges d'un protocol a un altre. Això és el que anomenem "Mail gateways" i en tenim un exemple a continuació:

Missatges SMTP
()[15/1]

Els missatges SMTP tenen un esquema molt simple que està destinat a ajudar al client de correu electrònic a organitzar i classificar els correus electrònics que emagatzemi.
L'estructura bàsica està formada per una capcelèra i un cos de missatge. La capcelera conté una serie de camps bàsics que s'identifican per paraules claus. Alguns exemples són:

. FROM: Nom del remitent. (No confondre amb l'ordre MAIL FROM)
. TO: Nom del destinatari. (No confondre amb l'ordre MAIL TO)
. SUBJECT: Tema del e-mail
. DATE: Data d'enviament
. CC i BCC: Copia en carbó

Seguidament el cos del missatge conté en format text pla el cos del missatge. Cal remarcar que la capcelera i el cos del e-mail estan separats per una linia en blanc i que el cos correu finalitzarà amb una altra linia amb un punt "."

Extensions MIME
()[15/1]

Tal i com em pogut veure, el cos del missatge només està previst que inclogui text normal i corrent. A més el fet que s'utlizi el format ASCII comporta una sèrie de limitacions que han fet del e-mail un protocol una mica limitat. Algunes d'aquestes limitacions són:

. El fet que els missatges estiguin en codificació ASCII evita que es puguin enviar missatges que utilitzin alfabets diferents.
. No es possible l'enviament de fitxers binaris.
. Alguns GATEWAYS pateixen sobrecàrrega degut a la necessitat de convertir entre formats.

Per tot això es van crear les MIME (Multiprupose Internet Mail Exchange). Aquestes són una serie de convencions de format que permeten intercanvia tot tipus d'informació a trvés dels correus electrònics. Inicialment, de fet, es van crear per aquest propòsit però amb el temps s'han utilitzan en altres protocols em ara el HTTP.

Concretament en els cas dels e-mails les MIME afegeixen, a més, una sèrie de noves capceleres orientades a indicar quin és el contingut del cos del e-mail.

Per a veure un llistat dels tipus MIME que existeixen podem vistiar: http://www.utoronto.ca/webdocs/HTMLdocs/Book/Book-3ed/appb/mimetype.html

Recuperacio de missatges i manipulació de busties
()[15/1]

El fet que la majoria de cases particulars no disposessin de conexió permanent a la xarxa suposa un problema determinant en el lliurament dels correus electrònis. Això, a més, s'agrauja degut a la limitació d'adreces estatàtiques i noms de domini que hi ha actualment. Per això cal afegir el paper d'un intermediari que emagatzemi el correu electronic fins que l'usuari no s'hi conecti i demani el contingut de la seva bustia.

Per a la recuperació dels e-mail cal un altre protocol que ens serveixi per a tenir un control remot de la bustia de correu que emagatzema el nostre servidor de correu. Dos dels protocols mes coneguts per a fer això són:

*. POP3 (Post Office Protocol) *. IMAP4 (Internet Message Access Protocol)

Els dos incorporen autentificació per a la a conexió al servidor. Cal tenir en compte però que aquests protocols només serveixen per a rebre el correu entrant ja que l'enviament dels e-mails es segueix fent directament des del usuari final. Un esquema que ilustra això podria ser el següent:

Fonts:

Apunts de la assignatura
http://es.wikipedia.org/wiki/POP3[[BR]] http://es.wikipedia.org/wiki/MIME
http://es.wikipedia.org/wiki/SMTP

Índex

4.3.2. HYPER TEXT TRANSFER PROTOCOL (HTTP)

()[15/1]

El World Wide Web
()[15/1]

El WWW (World Wide Web - Teranyina d'abast mundial - en català) És un conjunt de pagines web entrellaçades entre elles que poden contenir cualsevol tipus de dades. Inicialment aquestes pàgines web eren simples fitxers de texte que compartien "papers" d'investigació del CERN. Tim Berners-Lee va desenvolupar un prototip que enllaçava aquests documents entre ells per mitja de les URL (Uniform Resource Locator) i permetia veure anar saltant de document en document de forma sensilla.

Per a fer possible el WWW calen una serie de tecnologies que funcionant de manera conjunta. Aquestes tecnologies són:

. La URL (Uniform Resourece Locator) S'encarrega d'identificar de manera unica qualsevol document d'hipermedia que es trovi a la xarxa. La seva estructura consta del nom del protocol a utilizar, seguit del domini en el qual es troba el fitxer, seguit del port al qual es realitza la connexió i seguit del path del fitxer que volem.

. El protocol HTTP (Hipertext Transfer Protocol) . S'encarrega de la comunicació entre el client i el servidor. Gestiona les peticions dels clients i las respostes que els servidors retornen.
. HTML (?HiperText Markup Language) Es el llenguatge de marcatge de text per excl·lència de la WWW. S'encarrega d'estructurar el texte per a que pugui ser llegit per a un navegador i es mostrin els seus continguts de manera clara i ordenada a la pantalla.
. Navegador d'Internet. Es el client que del protocol HTTP. Es situa en l'espai d'usuari i s'encarrega de fer les peticions HTTP al servidor, rebre les respostes d'aquest i interpretar el llenguatge HTML per renderitzar en la pantalla el contingut del document.

Missatges HTTP
()[15/1]

El protocol HTTP (RFC 2068) és el que s'encarrega de les peticions per part dels clients i les respostes que aquests donen a les peticions. El funcionament bàsic del procés de navegació per la xarxa consisteix en els següents passos:

L'usuari escriu una adreça URL en el Navegador.
El navegador obté la IP del servidor que conté la URL que acaba d'introduïr l'usuari.
El navegador fa una petició HTTP (GET) al servidor de la URL per el port de la URL (80 normalment) demanant el fitxer que indica la url.
El servidor respon amb un missatge HTTP amb la informació solicitada per part de l'usuari. Aquesta informació pot ser qualsevol tipus de fitxer.

Cal tenir en compte que, si es tracta d'una pàgina HTML, en el moment en el que el navegador vagi interpretant el codi HTML anirà fent peticions HTTP successives al servidor Web per a obtenir tots els fitxers necessaris per a completar el renderitzat de la pàgina (per exemple imatges).

Els missatges HTTP són molt similars als missatges utilitzats en SMTP però en aquest cas les capcelesres que es poden utilitzar son força més exteneses. Cal diferenciar entre dos tipus de missatges, els de petició i els de resposta. Els dos tenen un format molt similar i només es diferencien per la primera línia del missatge. En el cas del missatge de petició la primera línia conté la paraula GET el path del fitxer que demana i la versió del protocol HTTP que està utilitzant. En el cas del missatge de resposta aquesta primera línia contindrà la versió del protocol HTTP i el codi d'estat de la resposta. Un exemple d'aquests missatges i la seva estructura el podem veure a continuació:

Altres aspectes del HTTP
()[15/1]

Cal tenir en compte una sèrie d'aspectes en consideració sobre l'HTTP.

. Els codis d'estat en els missatges de resposta del servidor són similars als utilitzats en FTP i SMTP.
. Per a identificar i codificar els diferents tipus de documents tambés s'utilitzen les extensions MIME
. Es un protocol sense estat. Això es veu clarament en el fet que les peticions dels fitxers es fan una a una amb diferens missatges GET I RESPONSE. A més això fa possible que es puguin fer proxies de navegació (gateways del protocol) o caches de navegació.
. Permet connexions persistens
. En tota conexió hi ha sempre negociació de la representació que s'utilizarà la connexió que es farà servir, el conitingut del document que s'intercanvia així com de diferents paràmetres de control com el temps de validesa.

Fonts:

Apunts de la assignatura
http://es.wikipedia.org/wiki/WWW
http://es.wikipedia.org/wiki/HTTP[[BR]] http://es.wikipedia.org/wiki/HTML
http://es.wikipedia.org/wiki/Navegador
http://es.wikipedia.org/wiki/URL

Índex

4.4. VIDEO I VEU SOBRE IP

Veu i Video sobre IP
()[15/1]

Per a transmetre per via telefònica se sol utilitzar PCM (Pulse Code Modulation). Aquesta modulació te en compte el fet que per a que un missatge de veu es pugui entendre correctament cal fer un mostrejat de la señal de veu de 8000 Hz, és a dir, 8000 mostres per segon amb una resolució de 8 bits per mostra. Si això ho haguessim de transmetre utilitzant la xarxa produciriem un fluxe de dades equivalent a 64Kbps.
Ara be, per a reduir l'ample de banda necessari per a transmetre la veu podriem pensar en tres possibles solucions:

. Reduïr la freqüència de mostreig -> Això faria que es perdés qualitat
. Reduïr la resolucio de les mostres -> També es disminuiria la qualitat.
. Comprimir les dades -> Augmentaria el delay, cosa no desitjable en comunicacions a temps real.

Per tant cal trobar alguna altra solució per al problema.

4.4.1. REAL TIME PROTOCOL (RTP)

(DanielMartín)
En les aplicacions real-time el temps és molt important. Si es perden dades és igual.

La capa de xarxa d’Internet no proporciona mecanismes vàlids pel transport de dades en temps real (pèrdues de datagrames, duplicacions, canvis d’ordre, ...).

Necessitem un nou protocol.

Real-Time Transport Protocol (RTP) Està pensat pel transport general de dades en temps real sobre internet, per exemple audio i video.

Soluciona els problemes d’arribada de datagrames fora d’ordre amb un número de seqüència.

Incorpora marques de temps (timestamps) per a que el jitter (endarreriments no previsibles) no afecti la reproducció.

Byte 0

Byte 1

Byte 2

Byte 3

V

P

X

CC

M

PT

Sequence Number

Time Stamp

Synchronization Source (SSRC)

Content Source (CSRC)

RTP número de versió (V - version number): 2 bits. La versió definida per l'especificació actual es 2.
Emplenat (P - Padding): 1 bit. Si el bit de padding està activat, hi ha un o mès bytes al final del paquet que no es part de la càrrega útil. El byte mès últim al paquet indica el número de bytes d'emplenat. L'emplenat es utilitzat per alguns algorismes d'encriptació.
L'extensió (X - Extension): 1 bit. Si el bit d'extensió està activat, llavors la capçalera fixa està seguida d'una extensió de la capçalera. Aquest mecanisme de l'extensió posibilita implementaciones per afegir informació a la capçalera RTP.
Conteig CSRC (CC): 4 bits. El número d'identificadors CSRC que segueix la capçalera fixa. Si es cero, llavors la font de sincronizació es la font de la càrrega útil.
El marcador (M - Marker): 1 bit. Un bit de marcador definit per el perfil particular de mijà.
La càrrega útil Type (PT): 7 bits. Un índex a una taula de perfils de mijà que descriu el format de càrrega útil. Els mapejats de càrrega útil per àudio i vídeo son definits a l'RFC 1890.
El número de Seqüencia: 16 bits. Un únic número de paquet que identifica la posició d'aquest a la seqüència de paquets. El número de paquet es incrementat en u per cada paquet enviat.
Timestamp: 32 bits. Reflexa l'instant de mostreig del primer byte a la càrrega útil. Varis paquets consecutius pòden tenir el mateix timestamp si sòn lógicament generats al mateix instant de temps -per exemple, si son del mateix fotograma de vídeo-.
SSRC: 32 bits. Identifica la font de sincronizació. Si el compte CSRC es cero, llavors la font de càrrega útil es la font de sincronizació. Si el compte CSRC es diferent a cero, llavors el SSRC identifica el mixer (mesclador).
CSRC: 32 bits cadascun. Identifica les fonts contribuients per la càrrega útil. El número de fonts contribuients està indicat pel camp del compte CSRC; Allà pot haber-hi mes de 16 fonts contribuients. Si hi ha fonts contribuients múltiples, llavors la càrrega útil son les dades mesclats d'aquestes fonts.

RTP suporta mixing (combinació de diferents fluxs), com per exemple en una multi-conferència, translation (canvi de codificació en estacions intermitges), i està dissenyat per a poder treballar amb multicast.

RTCP

Tot i que la ’T’ de RTP és de transport, normalment el trobem a la capa d’aplicació, sobre UDP. El port que utilitza depén de l’aplicació, i és senar.

RTP va acompanyat sempre de RTCP (Real-Time Control Protocol), que ofereix una canal paral.lel per dades de control.

RTCP també s’utilitza sobre UDP, en el port següent a l’utilitzat per RTP.

RTP Control Protocol (RTCP) es un protocol de comunicació que proporciona informació de control que està asociat a un fluxe d'informació per una aplicació multimèdia (fluxe RTP). Treballa junt RTP al transport i empaquetat de dades multumèdia, però no transporta ninguna dada per ell mateix. S'utilitza habitualmente per transmetre i rebre paquets de control als participants d'una sessió multimèdia d’streaming. La funció principal del RTCP es informar de la cualitat del servei proporcionada per RTP. Aquest protocol recull estadístiques de la connexió i tambiè informació com per exemple bytes enviats, paquets enviats, paquets perduts o jitter entre d'altres. Una aplicació pot usar aquesta informació per incrementar la qualitat de servei, ja sigui limitant el fluxe o utilitzant un códec de compresió mes baixa.

Fonts:

Apunts de clase.
http://es.wikipedia.org/wiki/RTCP
http://es.wikipedia.org/wiki/RTP

4.4.2. VEU SOBRE IP (VoIP)

(DanielMartín)

La transmissió de veu té els següents passos:

La veu de la persona s'enregistra com una senyal analògica. Per això s'utilitza un micròfon connectat a l'ordinador. O bé un telèfon comú que estè connectat a un dispositiu d'interconexiò ("gateway") entre la red de telefonía i una internet.
La senyal analògica es converteix en una senyal digital de forma comprimida.
S'envía per una internet en forma de datagrames IP
La màquina destinatària converteix les dades digitals a una senyal analògica.
La veu es recupera a travès dels altaveus.

Observació: Es garantitza una qualitat suficientment alta emprant protocols de comunicación (como RSVP) que reserven ample de banda per la transmissió dels datagrames IP.

Elements del estándar:

Terminals: Son els dispositius para telefonar. Es poden implementar tant en software como en hardware. Comunica amb el Gateway.
Gateways: Es tracta de l'enllaç amb la xarxa telefònica tradicional, actuant de forma transparent per l'usuari.
Gatekeepers: Son el centre de tota l'organizació VoIP (seríen els substituts de les actuals centraletes telefòniques). Normalment implementats en software, en cas d'existir, totes les comunicacions passaríen per ell.

L'estàndard H.323

La majoría dels programes de VoIP utilitzen l'estàndar H.323 o SIP. L'H.323 utilitza altres protocols de suport:

Direccionament:	RAS, DNS
Senyalització:	Q.931, H.225, H.245
Compressió de Veu:	G.711, G.723 (opcional: G.728, G.729, G.722)
Transmissió de Veu:	UDP, RTP (Real Time Protocol)

L'arquitectura de H.323 es veu en l'imatge següent:

attachment:arcitectura_H323.jpeg

Al dibuix surt un altre element que no hi es a la descripció anterior: El Multipoint Control Unit (MCU). Serveix per establir conferències entre tres o mes usuaris VoIP.

L'estàndard Session Initiation Protocol, SIP (IETF)

Es l'atre estàndard dominant, similar a H.323 però menys complert. No inclou compressió d'àudio ni vídeo.

Fonts:

Apunts de clase.
Wiki de XC2: http://www.naguissa.com/wiki-xc2/Voz_sobre_IP.html

Qualitat de servei (QoS) de flux en IP

Hi ha dos protocols proposats per l’IETF:

RSVP (Resource Reservation Protocol):
- Permet fer i contestar peticions de recursos (com ara d’amplada de banda).
- Proveeix un mecanisme per negociar amb la xarxa una qualitat de servei requerida per una connexió específica. S'utilitza quan es coneix l'ample de banda requerit, el retard i la probabilitat de pèrdua soportable.
- S'utilitza en protocols de VoIP, emissió de programes de televisió i diverses aplicacions sensibles a variacions de fluxe.
COPS (Common Open Policy Services):
- Quan els routers reben una petició de recursos han de mirar si és possible concedir-la i si les polítiques ho permeten. COPS s’utilitza per a implementar polítiques globals.
- COPS utilitza un model client/servidor on els Policy Enforcement Points (PEPs) envien peticions, modificacions i supresions als Policy Decision Point (PDPs) remots i els PDPs retornen les respostes als PEPs.
- COPS utilitza TCP com a protocol de transport per un intercanvi fiable.
- COPS es extensible des del seu disseny.
- COPS proporciona securetat i fiabilitat a nivell de missatge. COPS pot tambè utilitzar protocols existents de seguretat com IPSEC or TLS per auntentificar i assegurar el canat entre els PEPs i els PDPs.
- COPS es un protocol amb estatper os aspectes:
  1. Els estats Petició/Decissió es comparteixen entre el client i el servidor
  2. Els estats de viris events (parelles petició/decissió) poden anar associats.
  3. Adicionalment, COPS es un protocol amb estat ja que que permet al servidor enviar informació de configuració al client, i llavors permet al servidor el·liminar un estat al client que ja no es aplicable.
- Capçalera comú COPS:

4	8	16	32bits
Version	Flags	Op Code	Client-type
Message Length

- Version - El número de versió de COPS. La versió actial es 1.
- Flags - Si el bit 1 (Solicited Message Flag Bit) es a 1 indica que es un missatge solicitat per un altre missatge COPS. Tots els altres bits han de ser 0.
- Op Code - Codi d'operació COPS:
  - 1 Request (REQ);
  - 2 Decision (DEC);
  - 3 Report State (RPT);
  - 4 Delete Request State (DRQ);
  - 5 Synchronize State Req (SSQ);
  - 6 Client-Open (OPN);
  - 7 Client-Accept (CAT);
  - 8 Client-Close (CC);
  - 9 Keep-Alive (KA);
  - 10 Synchronize Complete (SSC)
- Client-type - Identifica la política del client.
- Message length - Tamany del missatge en octets, que inclou la capçalera estàndard COPS i tots els objectes encapsulats.

Fonts:

http://es.wikipedia.org/wiki/Rsvp
http://www.javvin.com/protocolCOPS.html

Índex

4.5. GESTIÓ DE XARXES

(DanielMartín)

4.5.1. SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP)

(DanielMartín)

El Protocolo Simple de administración de red o SNMP es un protocolo de la capa de aplicación que facilita el intercambio de información de administración entre dispositivos de red. Es parte de la suite de protocolos TCP/IP. SNMP permite a los administradores supervisar el desempeño de la red, buscar y resolver sus problemas, y planear su crecimiento.

Las versiones de SNMP más utilizadas son dos: SNMP versión 1 (SNMPv1) y SNMP versión 2 (SNMPv2). Ambas versiones tienen un número de características en común, pero SNMPv2 ofrece mejoras, como por ejemplo, operaciones adicionales.

SNMP en su última versión (SNMPv3) posee cambios significativos con relación a sus predecesores, sobre todo en aspectos de seguridad, sin embargo no ha sido mayoritariamente aceptado en la industria.

Componentes básicos de SNMP

Una red administrada a través SNMP consiste de tres componentes claves:

Dispositivos administrados: Un dispositivo administrado es un nodo de red que contiene un agente SNMP y reside en una red administrada. Estos recogen y almacenan información de administración, la cual es puesta a disposición de los NMS’s usando SNMP. Los dispositivos administrados, a veces llamados elementos de red, pueden ser routers, servidores de acceso, switches, bridges, hubs, computadores o impresoras.
Agentes: Un agente es un módulo de software de administración de red que reside en un dispositivo administrado. Un agente posee un conocimiento local de información de administración, la cual es traducida a un formato compatible con SNMP.
Sistemas administradores de red (NMS’s): Un NMS ejecuta aplicaciones que supervisan y controlan a los dispositivos administrados. Los NMS’s proporcionan el volumen de recursos de procesamiento y memoria requeridos para la administración de la red. Uno o más NMS’s deben existir en cualquier red administrada.

Comandos básicos de SNMP

Los dispositivos administrados son supervisados y controlados usando cuatro comandos SNMP básicos: Lectura, escritura, notificación y operaciones transversales.

El comando de lectura es usado por un NMS para supervisar elementos de red. El NMS examina diferentes variables que son mantenidas por los dispositivos administrados.

El comando de escritura es usado por un NMS para controlar elementos de red. El NMS cambia los valores de las variables almacenadas dentro de los dispositivos administrados.

El comando de notificación es usado por los dispositivos administrados para reportar eventos en forma asincrónica a un NMS. Cuando cierto tipo de evento ocurre, un dispositivo administrado envía una notificación al NMS.

Las operaciones transversales son usadas por el NMS para determinar qué variables soporta un dispositivo administrado y para recoger secuencialmente información en tablas de variables, como por ejemplo, una tabla de rutas.

Base de información de administración SNMP (MIB)

Una base de información de administración (MIB) es una colección de información que está organizada jerárquicamente. Las MIB’s son accedidas usando un protocolo de administración de red, como por ejemplo, SNMP.

Un objeto administrado (algunas veces llamado objeto MIB, objeto, o MIB) es uno de cualquier número de características específicas de un dispositivo administrado. Los objetos administrados están compuestos de una o más instancias de objeto, que son esencialmente variables.

Existen dos tipos de objetos administrados: Escalares y tabulares. Los objetos escalares definen una simple instancia de objeto. Los objetos tabulares definen múltiples instancias de objeto relacionadas que están agrupadas conjuntamente en tablas MIB.

Un ejemplo de un objeto administrado es atInput, que es un objeto escalar que contiene una simple instancia de objeto, el valor entero que indica el número total de paquetes ?AppleTalk de entrada sobre una interfaz de un router.

Un identificador de objeto (o object ID) únicamente identifica un objeto administrado en la jerarquía MIB. La jerarquía MIB puede ser representada como un árbol con una raíz anónima y los niveles que son asignados por diferentes organizaciones.

Los identificadores de los objetos ubicados en la parte superior del árbol pertenecen a diferentes organizaciones estándares, mientras los identificadores de los objetos ubicados en la parte inferior del árbol son colocados por las organizaciones asociadas.

Los vendedores pueden definir ramas privadas que incluyen los objetos administrados para sus propios productos. Las MIB’s que no han sido estandarizadas típicamente están localizadas en la rama experimental.

El corazón del árbol MIB se encuentra compuesto de varios grupos de objetos, los cuales en su conjunto son llamados mib-2. Los grupos son los siguientes:

System (1)
Interfaces (2)
AT (3)
IP (4)
ICMP (5)
TCP (6)
UDP (7)
EGP (8)
Transmission (10)
SNMP (11)

Mensajes SNMP

Para realizar las operaciones básicas de administración anteriormente nombradas, el protocolo SNMP utiliza un servicio no orientado a la conexión (UDP) para enviar un pequeño grupo de mensajes (PDU’s) entre los administradores y agentes. La utilización de un mecanismo de este tipo asegura que las tareas de administración de red no afectarán al rendimiento global de la misma, ya que se evita la utilización de mecanismos de control y recuperación como los de un servicio orientado a la conexión (TCP).

Los puertos asignados por la IANA para el protocolo SNMP son los siguientes: || Puerto/protocolo Descripción

161/tcp	SNMP
161/udp	SNMP
162/tcp	SNMP-trap
162/udp	SNMP-trap

?GetRequest: A través de este mensaje el NMS solicita al agente retornar el valor de un objeto de interés mediante su nombre. En respuesta el agente envía una respuesta indicando el éxito o fracaso del requerimiento. Si el requerimiento fue adecuado, el mensaje resultante también contendrá el valor del objeto solicitado. Este mensaje puede ser usado para recoger un valor de un objeto, o varios valores de varios objetos, a través del uso de listas.
?GetNextRequest: Este mensaje es usado para recorrer una tabla de objetos. Una vez que se ha usado un mensaje ?GetRequest para recoger el valor de un objeto, puede ser utilizado el mensaje ?GetNextRequest para repetir la operación con el siguiente objeto de la tabla. Siempre el resultado de la operación anterior será utilizado para la nueva consulta. De esta forma un NMS puede recorrer una tabla de largo variable hasta que haya extraído toda la información para cada fila existente.
?SetRequest: Este tipo de mensaje es utilizado por el NMS para solicitar a un agente modificar valores de objetos. Para realizar esta operación el NMS envía al agente una lista de nombres de objetos con sus correspondientes valores.
?GetResponse: Este mensaje es usado por el agente para responder un mensaje ?GetRequest, ?GetNextRequest, o ?SetRequest.
Trap: Un trap es generado por el agente para reportar ciertas condiciones y cambios de estado a un proceso de administración. SNMP inicialmente soportó un número limitado de traps desde los dispositivos administrados:
- Cold start: Indica que el agente ha sido inicializado o reinicializado.
- Warm start: Indica que la configuración del agente ha cambiado.
- Link down: Indica el cambio en el estado (fuera de servicio) de una interfaz de comunicación.
- Link up: Indica el cambio en el estado (en servicio) de una interfaz de comunicación.
- Authentication failure: Indica que el agente ha recibido un requerimiento de un administrador no autorizado.
- EGP neighbor loss: Indica que en sistemas en que los routers están utilizando el protocolo EGP, un equipo colindante se encuentra fuera de servicio. Todos los nuevos traps que son incluidos por los vendedores se encuentran clasificados en la categoría enterprise.
?GetBulkRequest: Este mensaje es usado por un NMS que utiliza la versión 2 del protocolo SNMP típicamente cuando es requerida una larga transmisión de datos, tal como la recuperación de largas tablas. En este sentido es similar al mensaje ?GetNextRequest usado en la versión 1 del protocolo, sin embargo, ?GetBulkRequest es un mensaje que implica un método mucho más rápido y eficiente, ya que a través de un solo mensaje es posible solicitar valores de múltiples objetos administrados.
?InformRequest: Un NMS que utiliza la versión 2 del protocolo SNMP transmite un mensaje de este tipo a otro NMS con las mismas características, para notificar información sobre objetos administrados.

Fuentes:

http://es.wikipedia.org/wiki/Simple_Network_Management_Protocol
http://www.ietf.org/rfc/rfc1157.txt

Índex

4.6. INICIALITZACIÓ I AUTOCONFIGURACIÓ

( y DanielMartín)

Resulta fundamental para cualquier máquina conectada en una red TCP/IP conocer una serie de datos para poder enviar y recibir datagramas. Estos datos podrían ser:

- La dirección IP, dato principal sin el cual el envío no sería posible.
- La dirección del router que hará de encaminador entre la red en la que esté el emisor y el exterior.
- La máscara de subred.
- La dirección de DNS.

Cómo ya hemos dicho estos datos son básicos para poder establecer una comunicación TCP/IP, pero que pasa si las máquinas que han de hacer la comunicación no disponen de la capacidad de almacenarla? Pues que en ese caso la han de obtener de la propia red.

Existen varios protocolos para facilitar esta tarea, entre los que están RARP, BOOTP y DHCP, en donde estos dos últimos trabajan bajo UDP con la dirección 255.255.255.255.
[BR]]

()

RARP (Reverse Address Resolution)

El formato de los mensajes es el mismo que en ARP y aquí se hace uso de la capa física para obtener la dirección IP des de un servidor

4.6.1. BOOTSTRAP PROTOCOL (BOOTP)

()

BOOTP (Bootstrap Protocol)

Para poder utilizar este protocolo es imprescindible que los mensajes UDP utilicen la opción de checksum y que tengan el bit de 'do not fragment' activado (1). Mediante BOOTP existe la posibilidad de recibir múltiples respuestas de entre las cuales se procesará únicamente la primera utilizando un ya clásico método de timeouts y retransmisiones.

El formato de los mensajes BOOTP es:

- OP ( 1 byte): byte de flan en donde 1 indica que es una petición y 0 que es una respuesta.
- HTYPE ( 1 byte): Indica el tipo de red física.
- HLEN ( 1 byte): Indica la longitud de la dirección física.
- HOPS ( 1 byte): Este campo se inicializa a 0 y va incrementando cada vez que pasa la petición a otro servidor.
- TRANSACTION IDENTIFIER (4 bytes)
- SECONDS ELAPSED (2 bytes)
- FLAGS (2 bytes)
- CLIENT IP ADDRESS (4 bytes)
- YOUR IP ADDRESS (4 bytes)
- SERVER IP ADDRESS (4 bytes)
- ROUTER IP ADDRESS (4 bytes)
- CLIENT HARDWARE ADDRESS (16 bytes)
- SERVER HOST NAME (64 bytes)

Los últimos 6 campos los ha de rellenar el cliente. Rellenará los que conozca y dejará el resto a cero.

- BOOT FILE NAME ( 128 bytes): Podemos tener diferentes imágenes para diferentes arquitecturas. En este campo es en donde se especifica cual es la que queremos usar. .
- OPTIONS ( tamaño variable): Otras opciones.

El funcionamiento de BOOTP lo podríamos dividir en dos pasos:

1.- Se obtiene la información de configuración de la red mediante BOOTP.
2.- Se recupera la imagen (por ejemplo a través del ya conocido protocolo TFTP) .

El problema de usar BOOTP es que 'está diseñado para entornos estáticos' en los que la topología de la red es estable. Esto hace que en entornos en donde exista máquinas que se conectan mediante wireless no se pueda usar, debido a que no permite asignar dinámicamente la información de esas máquinas.

4.6.2. DYNAMIC HOST CONFIGURATION PROTOCOL (DHCP)

()

DHCP (Dynamic Host Configuration Protocol)

DHCP es la mejora de BOOTP y permite su uso en redes dinámicas. Permite al cliente cambiar la información de configuración en un único mensaje, lo que facilita que una máquina nueva pueda unirse a la red y pueda obtener de forma rápida y dinámica una dirección IP. Esto se consigue dando una serie de direcciones IP al servidor. Luego este las asignará de forma dinámica a las máquinas que se lo pidan. Este tipo de configuración tiene varios tipos:

- Manual: Como en BOOTP, se asigna una dirección IP específica a una máquina en concreto.
- Automática: La asignación se realiza automáticamente en el momento en que una máquina se conecta.
- Dinámica: El servidor se asigna una dirección IP a la máquina que la solicita por un periodo de tiempo limitado.

Una de las características más importantes de DHCP es la compatibilidad con BOOTP. Esto se resume diciendo que cualquier servidor de DHCP puede contestar peticiones BOOTP.

En cuanto al formato de los mensajes en DHCP podemos decir que es el mismo que en BOOTP, salvo pequeñas variaciones como pueden ser los dos bytes del campo FLAGS en donde todos los bits excepto el primero tiene que ser cero.

DHCP usa normalmente la dirección hardware del cliente e información de la red para asignar las direcciones IP y el tiempo que las cede suele ser limitado.

1	Acceptar el missatge
	1a	Posar a la bústia del destinatari
	1b	Posar a la cua si cal reenviar
2	Verificar els destinataris
3	Comprovar errors