BIENVENIDOS
A estudiar compañeros
INTEGRANTES DEL EQUIPO:
CEVALLOS DÁVILA JOSUÉ
PONCE SALTOS YANINA
SABANDO VALDEZ NORA ELIZA
ZAMBRANO GERMANIA JESSENIA
PÁGINAS
ARCHIVOS DE PÁGINA
CAPA DE TRANSPORTE
miércoles, 2 de febrero de 2011
viernes, 28 de enero de 2011
jueves, 27 de enero de 2011
jueves, 20 de enero de 2011
Los Rfc's
RFC's
El hablar de RFC es comentar fundamentalmente en lo que significa la documentación de protocolos y tecnologías de Internet, es una sigla en Inglés llamada Request For Comments que simboliza a una solicitud de comentarios es decir un documento que puede ser relatado por cualquier persona y que a su vez contiene una idea, para hablar acerca del uso de tecnologías o recursos efectivos, para mejoras de tecnologías, proyectos experimentales y muchas cosas más.
Las RFC son accesibles por cualquier persona debido a que son publicadas on-line y sin restricciones.
La metodología que se utiliza con las RFC es asignarle a cada una un número único que la identifique y que es el consecutivo de la última RFC publicada.
Cabe recalcar que una RFC que esté publicada jamás puede modificarse, no existen varias versiones de una RFC, ya que lo que se hace, es escribir una nueva RFC que deje obsoleta o complemente una RFC anterior.
Para crear una nueva RFC puede utilizarse el sitio RFC Editor, que es donde se envían las nuevas propuestas que eventualmente podrán ser adoptadas como RFC y, si son de gran interés, convertirse en estándares.
La familia de protocolos de Internet está todavía evolucionando mediante el mecanismo de Petición de Comentario RFC. La mayoría de los protocolos de aplicación los han diseñado e implementado investigadores y científicos y han sido expuestos a la comunidad de Internet en forma de RFC.
La mayor fuente de RFCs es la Internet Engineering Task Force (IETF) que es un subsidiario del IAB. Sin embargo, cualquiera puede proponer una memorándum como un RFC al editor de RFC. Existe una serie de reglas que los autores de RFC deben seguir para que se acepten. Estas reglas se describen en un RFC 1543 que indica cómo considerar una propuesta para un RFC.
Una vez que se ha publicado un RFC, todas las revisiones y suplementos se publicarán como nuevos RFCs. Un nuevo RFC que revise o reemplace uno existente se dice "actualizado" u "obsoleto". El RFC existente se dice "actualizado por" un "obsoleto por" el nuevo.
Por ejemplo el RFC 1521 que describe el protocolo MIME es una "segunda edición", siendo una revisión del RFC 1341 y RFC 1590 es un corrección al RFC 1521. RFC 1521 es por tanto etiquetada como "Obsoleto RFC 1341; Actualizado por RFC 1590". Por consiguiente, no existe confusión alguna de si dos personas se están refiriendo a versiones diferentes de un RFC, dado que no hay nunca versiones diferentes.
Algunos RFCs se describen como documentos de información que otros describen protocolos Internet. El Internet Architecture Board (IAB) mantiene una lista de los RFCs que describen la familia de protocolos. Cada uno de estos tiene asignado un estado y un status.
Un protocolo de Internet puede tener uno de los siguientes estados:
Estándar
El IAB ha establecido esto como un protocolo oficial para Internet. Se separan en dos grupos:
1. Protocolo IP y citados, protocolos aplicados enteramente a Internet.
2. Protocolos específicos de red, generalmente especificaciones de cómo hacer IP sobre tipos particulares de redes.
Estándar Borrador
El IAB está considerando activamente este protocolo como un posible protocolo estándar. El IAB somete los comentarios y resultados de pruebas. Existe una posibilidad que cambia that changes will be made in a draft protocol before it becomes a standard.
Estándar Propuesto
Estos son protocolos propuestos que debe considerar IAB para su estandarización en el futuro. Son deseables implementaciones y comprobaciones de varios grupos. La revisión del protocolo es probable.
Experimental
Un sistema no debería implementar un protocolo experimental a no ser que esté participando en el experimento y ha coordinado su uso del protocolo con el desarrollador del protocolo.
Informativo
Los protocolos desarrollados por otras organizaciones, o vendedores, o que están por otras razones fuera del alcance de IAB deben publicarse como RFCs por conveniencia de la comunidad de Internet como protocolos informativos. Tales protocolos pueden en algunos casos también estar recomendados para uso en Internet por IAB.
Histórico
Estos son protocolos que con poca probabilidad llegan a ser estándares en Internet porque los han reemplazado los desarrolladores más tarde o por falta de interés.
DEFINICIONES DE ESTADO DEL PROTOCOLO:
Requerido
Un sistema debe implementar los protocolos requeridos.
Recomendado
Un sistema debe implementar los protocolos recomendados.
Electivo
Un sistema puede o no implementar un protocolo electivo. La noción general es que si se va a hacer algo como esto, se debe hacer exactamente esto.
Uso limitado
Estos protocolos están para usar en circunstancias limitadas. Esto puede ser debido a su estado experimental, naturaleza específica, funcionalidad limitada o estado histórico.
No recomendado
Estos protocolos no se recomiendan para uso general. Esto se puede deber a su funcionalidad limitada, naturaleza específica o estado experimental o histórico.
El estándar propuesto, el borrador y los protocolos estándar se describen como constituyentes del Internet Standards Track. El track estándar lo controla el Grupo de Dirección de Ingenieros de Internet (IESG) del IETF. Cuando un protocolo alcanza el estado de estándar se le asigna un número estándar (STD).
El propósito de los números STD es indicar claramente qué RFCs describen los estándares de Internet. Los números STD referencian múltiples RFCs cuando la especificación de un estándar se divide en múltiples documentos. No como con los RFCs, donde el número se refiere a un documento específico, los números STD no cambian cuando un estándar se actualiza. Los números STD, sin embargo, no tienen número de versión dado que todas las actualizaciones se realizan vía RFCs y los números de RFC son únicos.
De este modo, para especificar sin ambigüedad qué versión de un estándar único se está refiriendo, se pondría de manifiesto el número estándar y todos los RFCs que incluye. Por ejemplo, el Sistema de Nombres de Dominio (DNS) es STD 13 y se describe en los RFCs 1034 y 1035. Para referenciar el estándar se podría utilizar algo como "STD-13/RFC-1034/RFC-1035". Para una descripción de los Procesos Estándares, ver RFC 1602 -- Los Procesos Estándares de Internet - Revisión 2.
Para algunos estándares RFCs la categoría de status no siempre contiene suficiente información útil. Por lo tanto, se cumplimenta, notablemente por protocolos de enrutamiento por un applicability statement que se da en STD 1 o en un RFC separado.
Un determinado número de RFCs que tienen la intención de ser interesantes a los usuarios de Internet se clasifican como documentos Para Tu Información (FYI). Contienen frecuentemente información introductoria u otro tipo de información útil. Como los números de STD, un número de FYI no cambia cuando se emite la revisión de un RFC. Distintos STDs, FYIs corresponden a un único documento RFC. Por ejemplo, FYI 4 -- FYI sobre Preguntas y Respuestas - respuestas a preguntas comunes "Nuevo Usuario de Internet" está actualmente en su cuarta edición. Los números de RFC son 1177, 1206, 1325 y 1594.
Todos los RFCs están disponibles públicamente, tanto impresos como de forma electrónica desde el Centro de Información de la Red Internet o InterNIC (internic.net). Antes de 1993, la función del NIC estaba representada por el DDN NIC (nic.ddn.mil). Ver RFC 1400 para más información acerca de la transición.
Si un documento es considerando como candidato a norma, pasa por las fases de desarrollo, comprobación, y aceptación. Estas fases se etiquetan como niveles de desarrollo (Maturity levels). Existen 3 niveles para llegar a un standard de Internet.
Cuando un documento se publica, se le asigna un número de RFC. El RFC original nunca se actualiza, si se requieren cambios, se publica como un nuevo RFC con un número nuevo. Por consiguiente, es importante verificar que estemos trabajando con el RFC mas reciente.
En conclusión podríamos decir que las RFC es una serie de documentos iniciada en 1967 la cual describe el conjunto de protocolos de Internet y experimentos similares. No todos los RFC describen estándares de Internet pero todos los estándares Internet están escritos en formato RFC. La serie de documentos RFC es inusual en cuanto los protocolos que describen son elaborados por la comunidad Internet que desarrolla e investiga, en contraste con los protocolos revisados y estandarizados formalmente que son promovidos por organizaciones como CCITT y ANSI. El RFC 822 es el formato estándar Internet para cabeceras de mensajes de correo electrónico. El nombre viene del "RFC 822", que contiene esa especificación (STD 11, RFC 822). El formato 822 era conocido antes como formato 733.
Los rfcs son las normas del TCP/IP. Son los documentos que tenemos que leer si queremos hacer aplicaciones que funcionen con TCP/IP.
Las normas de TCP/IP se publican en una serie de documentos llamados Request for Comments (RFCs).
Los RFCs describen el funcionamiento interno de Internet. Algunos RFCs describen servicios de la red, protocolos y sus aplicaciones. Siempre se publican las normas del TCP/IP como RFCs.
Estas normas no están desarrolladas por un comité, sino por acuerdo general. Cualquiera puede escribir un documento para que se publique como un RFC. Estos documentos son revisados por un experto, una vez revisado se le asigna un estado, que especifica si un documento está considerando como una norma.
Bibliografía
Redes RFCS\Que son los RFC's - lanrouter_com.mht
"http://www.msci.magic.net/docs/rfc/rfc_by_num.html
Redes RFCS\Tutorial y descripción técnica de TCP-IP.mht
Redes RFCS\Tabla de RFC's de IPv6.mht