CONMUTADOR CORE

Estándares Soportados

Administración

RFC 854. Telnet: Especificaciones del protocolo Telnet

El protocolo Telnet es un protocolo de Internet estándar que permite

conectar terminales y aplicaciones en Internet. El protocolo proporciona

reglas básicas que permiten vincular a un cliente (sistema compuesto de

una pantalla y un teclado) con un intérprete de comandos (del lado del

servidor).

El protocolo Telnet se aplica en una conexión TCP para enviar datos en

formato ASCII codificados en 8 bits, entre los cuales se encuentran

secuencias de verificación Telnet. Por lo tanto, brinda un sistema de

comunicación orientado bidireccional (semidúplex) codificado en 8 bits y

fácil de implementar.

El protocolo Telnet se basa en tres conceptos básicos:

el paradigma Terminal virtual de red (NVT);

el principio de opciones negociadas;

las reglas de negociación.

RFC 855. Opción Telnet: Especificaciones de opciones de Telnet

Sección 1 - Nombre de la orden y código de opción Sección 2 - Significado de la orden Se debería describir el significado de cada posible orden TELNET

relevante. Para opciones complejas, donde se requiere "subnegociación",

puede haber un mayor número de órdenes posibles. El concepto de

"subnegociación" se describe con más detalle posteriormente.

Sección 3 - Especificación de valores por defecto : Se debe describir lo

que se asuma por defecto para ordenadores que no implementan o usan

la opción .

Sección 4 – Motivación: Una detallada explicación de los motivos para

inventar una opción en particular o para elegir una forma particular de la

opción es muy útil para aquellos que no están afectados (o no se dan

cuenta de que lo están) por el problema que esta opción va a resolver.

Sección 5 - Descripción (o Reglas de implementación) :La mera

definición del significado de la orden y la motivación no son siempre

suficientes para asegurar que dos implementaciones de una opción serán

capaces de comunicarse. Por tanto, se deberá proporcionar una

descripción más completa en la mayoría de los casos. Esta descripción

puede consistir en texto, un ejemplo de implementación, trucos para los

desarrolladores, etc.

RFC 1155. SMI v1

Estructura e identificación de Gestión de la Información para el

protocolo TCP / IP basados en internets

RFC 1157. SNMP: 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. Permite a los

administradores supervisar el funcionamiento de la red, buscar y

resolver sus problemas, y planear su crecimiento.

RFC 1867. Formularios HTML/2.0 con extensiones de carga de archivos

Desde carga de archivos es una característica que beneficiará a muchas

aplicaciones, esta propone una extensión de HTML para permitir que los

proveedores de información para expresar las peticiones de subida de

archivos de manera uniforme, y una representación MIME para subir

ficheros compatibles respuestas. Este memorándum define un Protocolo

Experimental para la comunidad de Internet.

RFC 1901. SNMP v2 basado en la comunidad

El uso de estas extensiones basadas en IP

Gestión de las estaciones pueden administrar los servidores RADIUS de

contabilidad.

RFC 3410. (Informativo): Introducción y aplicabilidad para la

estructura de administración estándar de Internet

Este marco se deriva de

y se basa en el original Internet estándar de gestión

Marco (SNMPv1) y la Dirección segundo estándar de Internet

Marco (SNMPv2).

La arquitectura está diseñada para ser modular para permitir la

evolución del

el marco con el tiempo

RFC 3411. Una arquitectura para describir las estructuras de

administración SNMP (diciembre de 2002)

La arquitectura está diseñada para ser modular para permitir la

evolución del protocolo SNMP estándares en el tiempo. Las partes

principales de la arquitectura son un Motor SNMP contiene un

subsistema de procesamiento de mensajes, una de Seguridad

RFC 3412. Procesamiento y despacho de mensajes (diciembre de 2002)

describe el mensaje de la tramitación y expedición de Simple Network

Management Protocol (SNMP) mensajes dentro de la SNMP

arquitectura. En él se definen los procedimientos para el envío de

potencia varias versiones de mensajes SNMP al mensaje de SNMP

adecuada Procesamiento de los modelos, y para el envío de PDU a las

aplicaciones SNMP.

RFC 3413. Aplicaciones SNMP (diciembre de 2002) describe cinco tipos

de gestión de red simple Protocol (SNMP) las aplicaciones que hacen uso

de un motor SNMP como Descrito en el STD 62, RFC 3411. Los tipos de

aplicación que se describe son generadores de comandos, los

respondedores de comando, los autores de notificación, Receptores de

notificación, así como los redireccionadores de proxy.

RFC 3414. Modelo de seguridad basado en el usuario (diciembre de

2002) modelo de seguridad basado en usuarios (USM) para Protocolo

simple de administración (SNMP) versión 3 para su uso en el

Arquitectura SNMP. En él se definen los elementos de procedimiento

para garantizar la seguridad SNMP nivel de mensaje. Este documento

también incluye un Gestión de la Información Base (MIB) para

monitorizar remotamente / gestión los parámetros de configuración de

este modelo de seguridad. Este documento hace obsoleto el RFC 2574.

RFC 3415. Modelo de control de acceso basado en la vista (diciembre de

2002) describe la Ver-Control de acceso basado en Modelo (VACM) Para

su utilización en el protocolo simple de administración de redes (SNMP)

Arquitectura. En él se definen los elementos de procedimiento para el

control de Acceso a la información de gestión. también incluye una

Base de información de administración (MIB) para la gestión de forma

remota. Parámetros de configuración de la Vista-Control de acceso

basado en Modelo.

RFC 3416. Versión 2 de operaciones del protocolo SNMP (diciembre de

2002)

Define la sintaxis y Elementos de procedimiento para el envío, recepción

y procesamiento de SNMP PDUs. Especifica un protocolo de normas de

Internet para la Comunidad de Internet, y solicita debate y sugerencias

para Mejoras. Por favor refiérase a la edición actual del "Internet Normas

Oficiales de Protocolo "(STD 1) para la normalización de estado y la

situación de este protocolo

RFC 3417. Asignaciones de transporte (diciembre de 2002)

Se define el transporte de simple de administración de redes Protocol

(SNMP) mensajes sobre diversos protocolos. Este documento obsoletes

RFC 1906.

Define la forma en que el SNMP mapas en un conjunto inicial de

transporte dominios. En el momento de escribir esto, estaban en marcha

los trabajos para definir una cartografía de IPv6, que se describe en

[RFC3419]. Otras asignaciones pueden ser definidas en el futuro.

RFC 3418. Base de información de administración (MIB) para el

protocolo simple de administración de redes (SNMP)

Se define los objetos administrados que describen el comportamiento de

un simple de administración de redes (SNMP) Protocolo de la entidad.

Este documento Obsoletes RFC 1907, de gestión de información para la

versión 2 de la Simple Protocolo de administración de red (SNMPv2).

RFC 4251. Arquitectura del protocolo SSH

The Secure Shell (SSH) es un protocolo de inicio de sesión remoto seguro

y otros servicios de red segura sobre una red insegura Este RFC describe

la arquitectura del protocolo SSH, así como la notación y terminología

utilizada en los documentos de protocolo SSH. Se discute el algoritmo

SSH, sistema que permite extensiones de locales de nombres. El

protocolo SSH consta de tres componentes principales: el Protocolo de

capa de transporte proporciona autenticación de servidor,

confidencialidad e integridad con perfect forward secrecy. ElProtocolo

de autenticación de usuario autentica el cliente al servidor. El Protocolo

de conexión multiplexa el túnel codificado en varios canales lógicos de

Detalles de estos protocolos están descritos en documentos separados.

RFC 4252. Protocolo de autenticación SSH

Este documento describe el protocolo marco y pública clave de

autenticación SSH, contraseña y métodos de autenticación de cliente

basado en el host.

Métodos de autenticación adicionales se describen en documentos

independientes de. Las ejecuciones de protocolo de autenticación SSH

encima el SSH Protocolo de capa de transporte y proporciona un solo

túnel autenticado para el Protocolo de conexión SSH.

RFC 4253. Protocolo de capa de transporte SSH

Este documento describe el Protocolo de capa de transporte SSH, que se

ejecuta normalmente sobre TCP/IP. El Protocolo puede utilizarse como

base para una serie de servicios de red segura. Proporciona protección de

la integridad, cifrado y autenticación de servidor. Puede también

proporcionar compresión. Clave método de intercambio, el algoritmo de

clave pública, el cifrado simétrico algoritmo, el algoritmo de

autenticación de mensaje y algoritmo hash son todo negociado. Este

documento también describe el método de intercambio de claves Diffie-

Hellman y el mínimo conjunto de algoritmos que son necesarios para

implementar el Protocolo de capa de transporte SSH.

RFC 4254. Protocolo de conexión SSH

Este documento describe el Protocolo de conexión SSH. Ofrece sesiones

de inicio de sesión interactivo, ejecución remota de comandos, remitido a

conexiones TCP/IP y transmitido X 11 conexiones. Todos estos canales

de son multiplexados en un solo túnel encriptado. Protocolo de conexión

del SSH ha sido diseñado para ejecutar en la parte superior del SSH

transporte protocolos de autenticación de usuario y capa.

RFC 4419. Intercambio de grupo por Diffie-Hellman para el protocolo de

capa de transporte SSH

Este memo describe un nuevo método de intercambio de claves para la

de Secure Shell (SSH) Protocolo. Permite al servidor SSH proponer

nuevos grupos en que se realiza el intercambio de claves Diffie-Hellman

para el cliente. La propone grupos no necesitan ser fijados y pueden

cambiar con el tiempo.

RFC 4716

Formato de archivo de clave pública SECSH

En este documento se detalla formalmente en un existente formato de

archivo de clave pública en uso para el intercambio de claves públicas

entre los diferentes Secure Shell (SSH) implementaciones.

Además, este documento define una representación textual estándar de

las huellas dactilares de claves SSH públicas.

IEEE 802.3. 10 Base-T

Este estándar describe un bus lógico 802.3 CSMA/CD sobre un cableado

de 4 pares trenzados el cual está configurado físicamente como una

estrella distribuida, capaz de transmitir datos a 10 Mbs en un máximo de

distancia de 100 mts.

IEEE 802.3u. 100 Base-T

IEEE 802.3 fue el primer intento para estandarizar ethernet. Aunque

hubo un campo de la cabecera que se definió de forma diferente,

posteriormente ha habido ampliaciones sucesivas al estándar que

cubrieron las ampliaciones de velocidad (Fast Ethernet, Gigabit Ethernet

y el de 10 Gigabits Ethernet), redes virtuales, hubs, conmutadores y

distintos tipos de medios, tanto de fibra óptica como de cables de cobre

(tanto par trenzado como coaxial).

Los estándares de este grupo no reflejan necesariamente lo que se usa en

la práctica, aunque a diferencia de otros grupos este suele estar cerca de

la realidad.

IEEE 802.3ab. 1000 Base-T

Emplea todos los cuatro pares de hilos del cable, transmitiendo

simultáneamente en ambos sentidos y por cada uno de ellos. Se

multiplica así por ocho la velocidad de modulación, a costa de aplicar un

sistema electrónico de cancelación de eco. Puede funcionar sobre cable

de categoría 5 mejorado (UTP 5e) o superior.

1000Base-T, recogido en la revisión IEEE 802.3ab, es un estándar para

redes de área local del tipo Gigabit Ethernet sobre cable de cobre

trenzado sin apantallamiento. Fue aprobado por el IEEE 802.3 en 1999.

Contenido

IEEE 802.3ac. Etiquetado VLAN

Extensión de la trama máxima a 1522 bytes (para permitir las "Q-tag")

Las Q-tag incluyen información para 802.1Q VLAN y manejan

prioridades según el estandar 802.1p

IEEE 802.3ad. Agregado de enlaces

La agregación de enlaces, o IEEE 802.3ad, es un término que indica el establecimiento de una red de datos que describe cómo utilizar varios enlaces Ethernet full-dúplex en la comunicación entre dos equipos, repartiendo el tráfico entre ambos. Se empezó a conocer a través de la empresa Kalpana, pero hoy son muchos los fabricantes que ofrecen esta funcionalidad para todas las velocidades de Ethernet. La mayoría de las implementaciones actuales se adecúan al apartado 43 del estándar de IEEE 802.3, designada informalmente como “802.3ad”.

Trunking o la agregación de enlaces es una manera económica de instalar una red de alta velocidad más rápida de lo que permita un solo puerto o dispositivo de la tecnología de que se disponga

IEEE 802.3ae. 10 GigE

EEE 802.3ae define una versión de Ethernet con una velocidad nominal

de 10 Gbit/s, diez veces más rápido que gigabit Ethernet.

El nuevo estándar 10-gigabit Ethernet contiene siete tipos de medios para

LAN, MAN y WAN. Ha sido especificado en el estándar suplementario

IEEE 802.3ae, y será incluido en una futura revisión del estándar IEEE

802.3.

IEEE 802.1D. Árbol de expansión 1

802.1D es el estándar de IEEE para bridges MAC (puentes MAC), que incluye bridging (técnica de reenvío de paquetes que usan los switches), el protocolo Spaning Tree y el funcionamiento de redes 802.11, entre otros.

También impide que los bucles que se forman cuando los puentes o los interruptores están interconectados a través de varias rutas.El algoritmo BPDU logra mediante el intercambio de mensajes con otros switches para detectar bucles y, a continuación, elimina el bucle por el cierre de puente seleccionado interfaces. Este algoritmo garantiza que hay una y sólo una ruta activa entre dos dispositivos de red.

IEEE 802.1S. Árbol de expansión múltiple

Esto es lo que Cisco hizo originalmente, pero la implementación estándar

IEEE 802.1s hecho esta mecánica más elegante. Antes de continuar

discutiendo la implementación del IEEE, vamos a definir la región MSTP

como una colección de interruptores, compartiendo el mismo punto de

vista de la partición de la topología física en conjunto de las topologías

lógicas. Durante dos interruptores para convertirse en miembros de una

misma región.

IEEE 802.1W. Árbol de expansión rápida 1

Contiene mejoras, retiene compatibilidad con su antecesor 802.1D

dejando algunos parámetros sin cambiar. Por ejemplo, RSTP mantiene el

mismo formato de BPDU que STP sólo que cambia el campo de versión,

el cual se le asigna el valor de 2.

GMRP. Registro de multidifusión de nivel 2 dinámico

Proporciona un mecanismo que permite a los puentes y las estaciones

finales para registrar dinámicamente la información de pertenencia a

grupos con los puentes MAC conectados al mismo segmento de LAN y

para que la información se difunda en todos los puentes de la LAN en

puente que soporte ampliado los servicios de filtrado. El funcionamiento

de GMRP se basa en los servicios prestados por el GARP.

GVRP. Registro VLAN dinámico

GVRP se basa en GARP (protocolo genérico de registro de atributos), un

protocolo que define los procedimientos por los cuales las estaciones

terminales e interruptores en una red de área local (LAN) se pueden

registrar y cancelar el registro de atributos, tales como identificadores o

direcciones, entre sí. Cada estación final y cambiar lo que tiene un

registro actualizado de todas las estaciones terminales y otros switches

que se pueden alcanzar. GVRP, como GARP, elimina el tráfico

innecesario en la red mediante la prevención de los intentos de transmitir

información a los usuarios no registrados. Además, es necesario

configurar manualmente sólo un interruptor y todos los otros

interruptores se configuran en consecuencia .

IEEE 802.1Q. LAN virtuales con VLAN basadas en puertos

Estándar IEEE 802.1Q especifica la operación de puentes de red de área

local virtual (VLAN), que soporte la operación VLAN dentro un IEEE

802 había puenteado LAN. Este suplemento al estándar IEEE 802.1Q

agrega la instalación de puentes VLAN utilizar múltiples árboles de

expansión, para tráfico pertenecientes a diferentes VLAN para fluir sobre

potencialmente diferentes caminos dentro de la LAN virtual puente

IEEE 802.1v. VLAN basadas en protocolos

IEEE 802.1p. Prioridad de Ethernet con asignación y aprovisionamiento

de usuarios

IEEE 802.1p es un estándar que proporciona priorización de tráfico y filtrado multicast dinámico. Esencialmente, proporciona un mecanismo para implementar Calidad de Servicio (QoS) a nivel de MAC (Media Access Control).Existen 8 clases diferentes de servicios, expresados por medio de 3 bits del campo prioridad de usuario (user_priority) de la cabecera IEEE 802.1Q añadida a la trama, asignando a cada paquete un nivel de prioridad entre 0 y 7. Aunque es un método de priorización bastante utilizado en entornos LAN, cuenta con varios inconvenientes, como el requerimiento de una etiqueta adicional de 4 bytes (definida en el estándar IEEE802.1Q). Además solo puede ser soportada en una LAN, ya que las etiquetas 802.1Q se eliminan cuando los paquetes pasan a través de un router.

IEEE 802.1X. Autenticación basada en puertos

Es una norma del IEEE para el control de acceso a red basada en puertos. Es parte del grupo de protocolos IEEE 802 (IEEE 802.1). Permite la autenticación de dispositivos conectados a un puerto LAN, estableciendo una conexión punto a punto o previniendo el acceso por ese puerto si la autenticación falla. Es utilizado en algunos puntos de acceso inalámbricos cerrados y se basa en el protocolo de autenticación extensible (EAP– RFC 2284). El RFC 2284 ha sido declarado obsoleto en favor del RFC 3748.802.1X está disponible en ciertos conmutadores de red y puede configurarse para autenticar nodos que están equipados con software suplicante. Esto elimina el acceso no autorizado a la red al nivel de la capa de enlace de datos.

IEEE 802.3x. Control de flujo

Full Duplex (Transmisión y Recepción simultanea) y el control de flujo.

RFC 768. UDP

Este Protocolo de Datagramas de Usuario (UDP: User Datagram Protocol) se define con la intención de hacer disponible un tipo de datagramas para la comunicación por intercambio de paquetes entre ordenadores en el entorno de un conjunto interconectado de redes de computadoras. Este protocolo asume que el Protocolo de Internet (IP: Internet Protocol) se utiliza como protocolo subyacente. Este protocolo aporta un procedimiento para que los programas de aplicación puedan enviar mensajes a otros programas con un mínimo de mecanismo de protocolo. El protocolo se orienta a transacciones, y tanto la entrega como la protección ante duplicados no se garantizan. Las aplicaciones que requieran de una entrega fiable y ordenada de secuencias de datos deberían utilizar el Protocolo de Control de Transmisión (TCP: Transmission Control Protocol).

RFC 783. TFTP

TFTP es un protocolo muy sencillo utiliza para transferir archivos. Es de

Esta que viene su nombre, Trivial File Transfer Protocol o TFTP. Cada

Nonterminal paquete es reconocido por separado. En este documento se

describen el protocolo y sus tipos de paquetes. En el documento también

se explica las razones detrás de algunas de las decisiones de diseño.

RFC 791. IP

Este documento especifica el Protocolo estándar de Internet del

Departamento de Defensa. Este documento se basa en seis ediciones

anteriores de la ARPA Protocolo de Internet

Especificación, y el presente texto se basa en gran medida de ellos. No

tienen sido muchos colaboradores de esta obra, tanto en términos de

conceptos y en términos de texto. Esta edición revisa aspectos de

direccionamiento, el error manejo, códigos de opción, y la seguridad,

precedencia, compartimentos, y funciones de manejo de restricción del

protocolo de Internet.

RFC 792. ICMP

El Protocolo Internet (IP) se utiliza para el servicio de datagramas de "host" a "host" en un sistema de redes interconectadas denominado Catenet . Los dispositivos de conexión de redes se denominan Pasarelas (Gateways). Los mensajes ICMP se envían usando la cabecera IP básica. El primer octeto de la parte de datos del datagrama es el campo de tipo ICMP; el valor de este campo determina el formato del resto de los datos. Los campos etiquetados como "no usado" están reservados para posteriores extensiones y deben ser cero al ser enviados, y los receptores no deberán usar estos campos (excepto para incluirlos en la suma de control)

RFC 793. TCP

Este documento describe el protocolo, estándar del DoD, de control de la transmisión (TCP). Ha habido nueve ediciones previas de la especificación de TCP por ARPA sobre las que el presente texto se basa enormemente. Ha habido muchos participantes en este trabajo tanto en términos de conceptos como de texto. Esta edición clarifica varios detalles y elimina los ajustes de tamaño de búfer al "final de carta" y reescribe el mecanismo de carta como una función de entrega inmediata.

RFC 826. ARP

El protocolo propuesto aquí es el resultado de un gran acuerdo a partir de un debate con varias personas, los más notables J. Noel Chiapa, Yogen Dalal y James E. Kulp, y comentarios de ayuda de David Moon. [El propósito de este RFC es presentar un método de Conversión de Direcciones de Protocolo (ej.: direcciones IP) a Direcciones de Red Local (ej.: direcciones Ethernet). Este es un tema de interés general en la comunidad ARPA Internet en este momento. El método propuesto aquí es presentado para su consideración y comentario. Esta no es la especificación de un estándar de Internet.]

RFC 951. BootP

Este RFC describe un IP / UDP protocolo de arranque (BOOTP), que

permite un sistema sin disco duro máquina cliente a descubrir su propia

dirección IP, la dirección de un servidor, y el nombre de un archivo que

se carga en memoria y ejecutados. La operación de arranque se puede

concebir como constituido por DOS FASES. Este RFC describe la primera

fase, que podría ser denominado "dirección bootfile determinación y

selección". Después de esto

La dirección y el nombre del archivo que se obtenga información, el

control pasa a la de la segunda fase de arranque, donde se produce una

transferencia de archivos. El archivoTransferencia normalmente utiliza el

protocolo TFTP , ya que es la intención de que las dos fases en PROM

residir en el cliente. Sin embargo BOOTP también podría trabajar con

otros protocolos como SFTP [3] o FTP.

RFC 1321. Algoritmo de resumen de mensajes

Este documento describe el algoritmo de resumen de mensajes MD5. El algoritmo toma como entrada un mensaje de longitud arbitraria y produce como salida una "huella" de 128 bits o "resumen del mensaje" de entrada. Se conjetura que es computacionalmente inviable encontrar dos mensajes que tengan el mismo resumen, u obtener un mensaje que tenga un resumen de mensaje en concreto, establecido previamente como objetivo. El algoritmo MD5 está pensado para ser aplicado en firmas digitales, donde un archivo grande debe ser "comprimido" de forma segura antes de ser cifrado con una llave privada (secreta) dentro de un sistema de cifrado de llave pública, como RSA. El algoritmo MD

RFC 1534. Interoperación entre BootP y DHCP

DHCP proporciona un superconjunto de las funciones proporcionadas

por BOOTP. Este Documento se describe las interacciones entre DHCP y

BOOTP red Participantes.

RFC 2030. Protocolo simple de tiempo de red (SNTP) versión 4 para

IPv4, IPv6 y OSI

Describe el Simple Network Time Protocol (SNTP) versión 4, que es una

adaptación del Protocolo de Tiempo de Red (NTP) Utilizado para sincronizar

relojes en el Internet. SNTP se puede utilizar cuando el rendimiento final de la

plena aplicación NTP.

Descrito en el RFC-1305 no es necesaria o justificada. Al operar con

Actuales y anteriores versiones SNTP y NTP, SNTP versión 4 implica Sin

cambios en la especificación o NTP implementaciones conocidas, pero Más bien

una aclaración de algunas de las características de diseño que permiten NTP En

una simple operación, apátridas llamada de procedimiento remoto (RPC)

Modalidad.

Con precisión y fiabilidad las expectativas similares a la UDP / HORA

Protocolo descrito en el RFC-868.

RFC 2131. Cliente/servidor DHCP

El Protocolo de configuración dinámica de Host (DHCP) proporciona un marco

para pasar información de configuración a hosts en una red TCPIP. DHCP se

basa en el Protocolo Bootstrap (BOOTP) , agregando la capacidad de asignación

automática de direcciones de red reutilizable y opciones de configuración

adicionales. DHCP capta el comportamiento de los agentes de retransmisión

BOOTP y los participantes DHCP pueden interoperar con participantes

BOOTP

RFC 2132. Extensiones de proveedor BootP y opciones DHCP

Este documento especifica el conjunto actual de opciones DHCP. Opciones de

futuras se especificará en RFC separadas.

Todos del proveedor información extensiones definidas en RFC 1497 [2] pueden

utilizarse como opciones de DHCP. Las definiciones dadas en 1497 de RFC son

incluidas en este documento, que sustituye a RFC 1497. Todas las opciones de

DHCP definidas en este documento, excepto aquellos específicos de DHCP, tal

como se define en la sección 9, puede utilizarse como información de proveedor

BOOTP extensiones.

RFC 2865. Cliente RADIUS

Este protocolo es ampliamente implementado y utilizado. La experiencia ha demostrado que puede sufrir el menor performance y pérdida de datos cuando se utiliza en sistemas de gran escala de, en parte porque no incluye disposiciones para control de congestión. Los lectores de este documento pueden ser beneficioso para seguir el progreso del grupo de trabajo de la IETF AAA, cuestiones de control que puede desarrollar un protocolo sucesor que mejor trata la escala y congestión.

Este documento describe un protocolo para transportar información de

configuración entre un acceso a la red , autenticación y autorización de servidor

que desee autenticar sus vínculos y una compartida servidor de autenticación.

RFC 2866. Contabilidad RADIUS

Este documento describe un protocolo para llevar contabilidad información entre

un servidor de acceso de red y una contabilidad compartida Server.

El servidor de cuentas RADIUS puede actuar como un cliente proxy otros tipos

de servidores de contabilidad.

RFC 2868. Atributos RADIUS para compatibilidad con el protocolo de

túnel

Este documento define un conjunto de atributos RADIUS diseñado para apoyar

a la prestación de túneles obligatorios en redes de dial-up.

RFC 2869. Extensiones RADIUS

Este documento describe los atributos adicionales para llevar a cabo la

autenticación, la autorización y la información contable entre un servidor de

acceso de red (NAS) y un servidor de cuentas compartidas mediante el Protocolo

de autenticación Dial en usuario servicio remota (RADIUS) se describe en RFC

2865 y 2866 de RFC. Este memorando proporciona información para la

comunidad de Internet.

RFC 3164. El protocolo Syslog de BSD

Este documento describe el comportamiento observado del Protocolo syslog. este

protocolo ha sido utilizado para la transmisión del evento mensajes de

notificación a través de redes durante muchos años. Si bien este protocolo

originalmente fue desarrollado en la Universidad de California

implementaciones del sistema de Berkeley Software Distribution (BSD) TCP/IP,

su valor a las operaciones y gestión ha llevado a ser portado a muchos otros

sistemas operativos como ser incorporado muchos otros dispositivos de red.

RFC 3580. Pautas de uso de RADIUS 802.1X Este documento proporciona sugerencias sobre Remote Authentication Dial en el uso de servicio de usuario (RADIUS) por autenticadores de IEEE 802.1X. El material de en este documento también se incluye dentro de un normativo Apéndice dentro de la especificación IEEE 802.1X y se presenta como un IETF RFC para fines informativos.

RFC 4541. Supervisión IGMP y supervisión MLD

Este memo describe las recomendaciones para la administración del grupo InternetProtocol (IGMP) y descubrimiento de escucha de multidifusión (MLD), interruptores espionaje. Estas se basan en las mejores prácticas actuales para IGMPv2, con más consideraciones para IGMPv3 - y MLDv2-espionaje. También son consideradas áreas adicionales de de relevancia, tales como cambios de topología de capa de enlace y temas de Encapsulación Ethernet específico,.

IEEE 802.1AB. LLDP Este documento define un protocolo y un conjunto de objetos administrados que se pueden utilizar para descubrir la topología y conexión punto final información física de dispositivos adyacentes en 802 LAN y MANs. El Protocolo no está restringido de la ejecución en medios no 802. Sin embargo, especificación para la operación de medios de comunicación no 802 está fuera del alcance de este documento.

Enrutamiento

RFC 826. ARP de Ethernet

La aplicación de P en un protocolo de envío de acogida S decide,

A través del protocolo de enrutamiento P mecanismo, que quiere

transmitir a un blanco ubicado a unos receptores T lugar en una

pieza conectado de 10Mbit cable Ethernet. Para transmitir la

realidad de paquetes de Ethernet 48.bit una dirección Ethernet

deben generarse. Las direcciones de P hosts dentro de protocolo

no siempre son compatibles con las correspondiente dirección

Ethernet (por ser diferentes longitudes o Valores)

RFC 894. Transmisión de datagramas IP a través de redes Ethernet

Transmisión de datagramas IP a través de redes Ethernet

Este RFC especifica un método estándar de encapsulamiento de

Internet Protocolo (IP) datagramas sobre una Ethernet . Este RFC

especifica un Protocolo estándar para la comunidad ARPA-

Internet. Datagramas IP se transmiten en tramas Ethernet

estándar. El tipo Ámbito de la Ethernet marco debe contener el

valor hexadecimal 0800. El campo de datos contiene la cabecera IP

seguida inmediatamente de la propiedad intelectual Datos va ser

el otro Fin de la conversación

RFC 896. Control de congestión en redes IP/TCP

La congestión en el control de IP / TCP Internetworks

Control de transmisión Protocolo (TCP), un protocolo de capa de

transporte, cuando se utilizan juntos, Son objeto de inusuales

problemas de congestión causados por interacciones Entre el

transporte y las capas datagrama. En particular, de propiedad

intelectual Gateways son vulnerables a un fenómeno que

llamamos "la congestión col – Lapse ", en particular cuando dichas

pasarelas conectar redes de ampli Diferente ancho de banda.

Hemos desarrollado soluciones que impidan Congestión del

colapso.

RFC 1027. Uso de ARP para implementar puertas de enlace de

subred transparentes (ARP proxy)

Por lo tanto, un método para ocultar la existencia de subredes de

hosts Es muy conveniente. Puesto que todas las redes de área local

apoyado ARP, un método basado en ARP (comúnmente conocido

como "Proxy ARP" o el "ARP Hack ") fue elegido. En esta nota,

siempre que el término" subred "se produce "RFC-950 subred

método"

RFC 1256. Mensajes de descubrimiento de enrutador ICMP

especifica una extensión del mensaje de control de Internet

(ICMP) para permitir a los hosts conectados a la difusión o

multidifusión redes para descubrir las direcciones IP de sus

routers vecinos.

RFC 1321. Algoritmo de resumen de mensajes

Describe el MD5 Message-Digest Algorithm. La algoritmo toma

como entrada un mensaje de longitud arbitraria y produce como

salida de un 128-bit "huella digital" o "compendio del mensaje" de

la entrada. Se conjetura que es computacionalmente imposible de

producir dos mensajes que tengan la síntesis del mensaje mismo,

o para producir cualquier mensaje que tiene un determinado

resumen preespecificado mensaje de destino. El MD5 algoritmo

está diseñado para aplicaciones de firma digital, si una archivo de

gran tamaño deben ser "comprimido" de una manera segura antes

de ser encriptado con una clave privada (secreta) bajo un sistema

criptográfico de clave pública

RFC 1519. CIDR

analiza las estrategias para abordar la cesión de los actuales

Espacio de direcciones IP con el fin de conservar el espacio de

direcciones y tallo El crecimiento explosivo de las tablas de

enrutamiento en la ruta por defecto libre de routers.

RFC 1765. Desbordamiento de bases de datos OSPF

Funcionamiento del protocolo OSPF requiere que todos los

routers OSPF Mantener una copia idéntica de la relación Estado-

OSPF base de datos. Sin embargo, Cuando el tamaño de la

relación Estado-se convierte en la base de datos muy grandes,

algunos Routers puede ser incapaz de mantener a toda la base de

datos debido a los recursos Escasez; que este término "base de

datos de desbordamiento". Cuando la base de datos de

desbordamiento Se prevé, los routers con recursos limitados se

puede Alojados por la configuración de OSPF talón y áreas

NSSAs.

RFC 1812. Requisitos para enrutadores IP versión 4

Define y analiza los requisitos para los dispositivos que realizan la

función de reenvío de la capa de red de la suite de protocolo de

Internet. [NORMAS TRACK]

RFC 2131. Retransmisión DHCP

El Protocolo de configuración dinámica de Host (DHCP)

proporciona un marco para pasar información de configuración a

hosts en una red TCPIP. DHCP está basada en Protocolo

Bootstrap (BOOTP), añadiendo la capacidad de asignación

automática de direcciones de red reutilizable y opciones de

configuración adicionales. [NORMAS-TRACK]

RFC 2328. OSPF versión 2

Es un protocolo de enrutamiento de estado de enlace de Está

diseñado para ejecutarse interna a un único sistema autónomo.

Cada router OSPF mantiene una base de datos idéntica que

describe la topología del sistema autónomo. Desde esta base de

datos de, una tabla de enrutamiento se calcula mediante la

construcción de un árbol de ruta más corta.

RFC 2453. RIP v2

Especifica una extensión del Protocolo (RIP), tal como se definen

en "Protocolo de información de enrutamiento", para ampliar la

cantidad de información útil de mensajes RIP y para agregar una

medida de seguridad de la información de enrutamiento.

RFC 3046. Retransmisión DHCP/BootP

DHCP Opción que contiene una o varias "sub-opciones" que

transmitir Información conocida por el agente. El primer sub-

opciones son Definida por un agente que es co-ubicado en un

circuito público Acceso a la unidad. Estos incluyen un "circuito

ID" para el próximo circuito, Y una "remota ID", que proporciona

un identificador de confianza para el mando a distancia Módem

de alta velocidad.

RFC 3101. La opción de área no exclusiva de rutas internas ("Not

So Stubby Area", NSSA) de OSPF

Documenta un tipo opcional de abrir primero la ruta más corta

(OSPF) que algo humorísticamente se conoce como una zona de

"no-para-stubby" (o NSSA). NSSAs son similares a la opción de

configuración de área OSPF stub existente pero tienen la

capacidad adicional de importación como rutas externas de forma

limitada.

El OSPF NSSA opción fue originalmente definido en RFC 1587 (->

3101prop). Las diferencias funcionales entre este memo y RFC

1587 (-> 3101prop) son explicadas en el apéndice f el. Todas las

diferencias, durante la expansión de capacidad, son compatibles

con versiones anteriores en la naturaleza. Interoperan

implementaciones de este memo y RFC 1587 (-> 3101prop).

RFC 3768. VRRP: Protocolo de redundancia de enrutador virtual

Define el Virtual Router Redundancy Protocol (VRRP). VRRP

especifica una elección de protocolo que asigna dinámicamente

La responsabilidad de un router virtual a uno de los routers en

una VRRP LAN. El enrutador VRRP control de la dirección IP (es)

asociado con Router virtual que se llama el Maestro, y envía los

paquetes enviados a Estas direcciones IP. El proceso electoral no

ofrece más dinámico En la transmisión de la responsabilidad debe

convertirse en el Maestro Fuera de servicio.

RFC 2474. Definición del campo de servicios diferenciados (campo

DS) en los encabezados de IPv4 e IPv6

Especifica un protocolo de normas de Internet para la

Comunidad de Internet, y solicita debate y sugerencias para

Mejoras. el Protocolo de Internet son previsto permitir

discriminación de servicio escalable en Internet sin necesidad de

estado por el flujo y la señalización en cada salto. Una variedad de

servicios puede ser construida de un conjunto de bloques de

construcción de que se implementan en los nodos de la red

pequeño y bien definido.

RFC 2475. Una arquitectura para servicios diferenciados

Define una arquitectura para la implementación de diferenciación

de servicio escalable en Internet. Esta arquitectura logra

escalabilidad agregando estado de clasificación de tráfico que se

transmite mediante el marcado de paquetes de la capa IP

utilizando el campo DS [DSFIELD]. Paquetes están clasificados y

marcados para recibir un comportamiento de reenvío particular

por salto en nodos a lo largo de su camino. Clasificación

sofisticada, marcado, policía y operaciones de modelado necesitan

aplicarse sólo en los límites de la red o hosts.

RFC 2597. Comportamiento por salto (PHB) de reenvío asegurado

Define un uso general de servicios diferenciados (DS)

comportamiento por salto (PHB) grupo llamado reenvío

asegurado (AF). El grupo de AF PHB proporciona entrega de

paquetes IP en cuatro transmitido independientemente las clases

de AF. Dentro de cada clase de AF, una IP paquete puede

asignarse una de tres diferentes niveles de gota prioridad. Un

nodo de DS no reordenar los paquetes IP de los esterilizadores de

mismo si pertenecen a la misma clase de AF.

RFC 3246. Un PHB de reenvío acelerado

Define un PHB (comportamiento por salto) llamado acelerada

reenvío (EF). El PHB es un bloque de construcción básico en la

arquitectura de servicios diferenciados de EF está diseñado para

proporcionar un bloque de creación de para bajo retardo, jitter

baja y servicios de baja pérdida asegurando que el agregado EF se

sirve a una cierta tasa configurado. Este documento obsoletes

RFC 2598.

RFC 3260. Nueva terminología y aclaraciones para servicios

diferenciados (DiffServ)

captura Diffserv trabajando acuerdos de grupo relativos a nuevo y

mejorada de la terminología y proporciona menores aclaraciones

técnicas de . Se pretende actualizar el RFC 2474, RFC 2475 y RFC

2597. Cuando RFC 2474 y 2597 avance sobre las normas de

seguimiento y RFC 2475 se actualiza, se pretende que se

incorporarán a las revisiones en este memo , y que este memo se

ser sustituída por la nueva RFC

.

802.1p Prioridad de usuarios (etiqueta de VLAN externa o

interna)

Es un estándar que proporciona priorización de tráfico y filtrado

multicast dinámico. Esencialmente, proporciona un mecanismo

para implementar Calidad de Servicio (QoS) a nivel de MAC

(Media Access Control).

RFC 1112. Extensiones de host para multidifusión IP (IGMPv1)

Especifica las extensiones requeridas de una aplicación de host

del Protocolo Internet (IP) que admiten la multidifusión. Es el

recomienda estándar para multidifusión IP en Internet.

RFC 2236. IGMPv2

Documentos IGMPv2, utilizada los hosts IP para informar su

multidifusión grupo membresías a enrutadores. Actualiza STD 5,

RFC 1112. IGMPv2 permite la terminación de membresía de

grupo rápidamente informó a el Protocolo de enrutamiento, que

es importante para grupos multicast de de alto ancho de banda o

subredes con la pertenencia a un grupo altamente volátiles.

RFC 2710. MLDv1

Multicast Listener Discovery (MLD) para IPv6 especifica el

protocolo utilizado por un enrutador IPv6 descubrir la presencia

de agentes de escucha de multidifusión (es decir, los nodos que

deseen para recibir paquetes de multidifusión) en sus enlaces

conectados directamente y a descubrir específicamente las

direcciones multidifusión son de interés para los nodos vecinos.

Este protocolo se conoce como de Multicast Listener Discovery o

MLD. MLD se deriva de la versión 2 de IPv4 Internet Group

Management Protocol, IGMPv2. Una diferencia importante Nota

es ese mensaje de MLD usos ICMPv6 (protocolo IP 58) tipos, en

lugar de tipos de mensajes IGMP (Protocolo de IP 2).

RFC 3376. Protocolo de administración de grupos de Internet,

versión 3 (IGMPv3)

Especifica la versión 3 de la dirección del grupo de Internet

Protocol, IGMPv3. IGMP es el protocolo utilizado por sistemas

IPv4 informe su multidifusión IP grupo membresías a los vecinos

de enrutadores de multidifusión . La versión 3 de IGMP agrega

soporte para filtrado de"fuente", que es, la capacidad de un

sistema de interés del informe en la recepción de paquetes * sólo *

de direcciones de origen específico, o de * todos pero fuente

direcciones específicas, enviadas a una dirección de multidifusión

específica. Que información puede utilizarse por protocolos de

enrutamiento de multidifusión para evitar entregando paquetes

de multidifusión de fuentes específicas para redes donde no hay

ningún receptores interesados.

RFC 3810. MLDv2

Especifica la versión 2 de la Protocolo de descubrimiento de

escucha de multidifusión (MLDv2). MLD utiliza un enrutador

IPv6 de para descubrir la presencia de agentes de escucha de

multidifusión en había conectado directamente enlaces, y para

descubrir qué multidifusión las direcciones son de interés para

los nodos vecinos. MLDv2 está diseñado para ser interoperables

con MLDv1. MLDv2 agrega la posibilidad de que un nodo al

interés de informe de en la escucha de paquetes con una dirección

particular de multidifusión sólo desde direcciones de origen

específico o de todas las fuentes excepto direcciones de origen

específico.

RFC 4601. PIM-SM

Protocolo de multidifusión independiente - modo disperso (PIM-

SM): especificación de protocolo de (revisado)

Específica multidifusión independiente de protocolo: modo de

escaso (PIM-SM). PIM-SM es un protocolo de enrutamiento de

multidifusión que puede utilizar la subyacente unidifusión

información de enrutamiento base o un independiente de

multidifusión capaz información de enrutamiento base. Construye

unidireccional compartido árboles arraigados en un punto de

encuentro (RP) por grupo, y opcionalmente crea la ruta más corta

árboles por fuente.

RFC 2365. Límites de ámbito administrativo

Define el "ámbito administrativamente IPv4 multicast espacio" a

ser el rango 239.0.0.0 a 239.255.255.255. Además, describe un

conjunto simple de semántica para la aplicación del ámbito de

multidifusión de IP administrativamente. Finalmente,

proporciona una asignación de entre el IPv6 direcciones de

multidifusión clases [RFC1884] y IPv4 multicast abordar clases.

Este memo es un producto de la MBONE despliegue de trabajo

grupo (MBONED) en las operaciones y el área de gestión de la

ingeniería de Internet fuerza de tarea.

RFC 3973. PIM-DM

Específica multidifusión independiente de protocolo: modo denso

(PIM-DM). PIM-DM es un protocolo de enrutamiento de

multidifusión que utiliza la subyacente información enrutamiento

unidifusión de base a inundar los datagramas de multidifusión a

todos los enrutadores de multidifusión. Ciruela pasa mensajes se

utilizan para prevenir futuros mensajes de plantones para routers

sin información de pertenencia al grupo.

Enrutamiento IPv6

RFC 1981. MTU de ruta para IPv6

Describe el descubrimiento de MTU de ruta para IP versión

6. Es en gran parte derivado de RFC 1191, que describe el

descubrimiento de MTU de ruta para IP versión 4.

RFC 2373. Direcciones IPv6

Define la arquitectura de abordar el período de

investigación La versión 6 de protocolo [IPV6]. En el

documento se incluye el abordar IPv6 Modelo, el texto

representaciones de direcciones IPv6, la definición de IPv6

Direcciones unicast, anycast direcciones, y direcciones

multicast, y un IPv6 del nodo requiere direcciones.

RFC 2460. Especificación del protocolo IPv6

Este documento especifica la versión 6 del Protocolo

Internet (IPv6), algunas veces también referido como IP

Siguiente Generación o IPng.

RFC 2461. Descubrimiento de vecinos

Especifica el Protocolo de descubrimiento de vecinos para

IP versión 6. Nodos IPv6 en el mismo uso de enlace ND a

descubren la presencia del otro determinar la otra capa de

vínculo direcciones, encontrar routers y mantener

información de accesibilidad sobre los caminos a vecinos

activas.

RFC 2462. Autoconfiguración sin estado

Especifica los pasos que toma un host en decidir cómo

Autoconfigurar sus interfaces IP versión 6. La

configuración automática de proceso incluye la creación de

una dirección local del vínculo y verificar su singularidad

de en un vínculo, determinar qué información debe ser se

autoconfigure (direcciones, otra información o ambos), y en

el caso de direcciones, si se debe obtener mediante el

mecanismo de apátridas de, el mecanismo de seguimiento

de Estado o ambos.

RFC 2464. IPv6 sobre Ethernet

Especifica el formato de marco para la transmisión de

paquetes IPv6 y el método de formación de direcciones

locales del vínculo de IPv6 y statelessly direcciones

configuradas automáticamente en las redes Ethernet.

También especifica el contenido de la opción de dirección

de capa de vínculo de origen/destino utilizada en los

mensajes de solicitud de enrutador, anuncio de enrutador,

Neighbor Solicitation, anuncio de vecino y redirección

cuando los mensajes se transmiten en una Ethernet.

RFC 2711. Alerta de enrutador IPv6

Describe un nuevo tipo de opción de salto por salto de IPv6

que alerta de los enrutadores de tránsito de para examinar

más de cerca el contenido de una IP datagrama. Esta

opción es útil para situaciones donde un datagrama

dirigido a un determinado destino contiene información

que puede requieren un procesamiento especial por los

enrutadores de la ruta.

RFC 2740. OSPFv3

Describe las modificaciones de OSPF para apoyar de

versión 6 del Protocolo de Internet (IPv6). Los mecanismos

fundamentales de OSPF (inundaciones, elección de DR,

soporte de área, cálculos de SPF, etc.). Permanecen

inalterados. Sin embargo, algunos cambios han sido

necesarios, ya sea debido a cambios en la semántica de

protocolo entre IPv4 e IPv6, o simplemente para controlar

el tamaño de aumento de la dirección de IPv6.

RFC 3315. DHCPv6 (sin estado + retransmisión)

El Protocolo de configuración dinámica de Host para IPv6

(DHCP) permite DHCP servidores para pasar parámetros

de configuración como IPv6 red nodos IPv6 las direcciones

. Ofrece la capacidad de la asignación automática de

direcciones de red reutilizable y configuración adicional

flexibilidad. Este protocolo es una contraparte stateful

"IPv6 Stateless Address Autoconfiguration" (RFC 2462), y

puede ser usado por separado o simultáneamente con éste

para obtener la configuración de los parámetros

RFC 3484. Selección de dirección predeterminada para IPv6

describe dos algoritmos, para la selección de direcciones de

origen y selección de direcciones de destino. Los

algoritmos de especifican el comportamiento

predeterminado de para todos los Protocolo de Internet

versión 6 (IPv6) implementaciones de . Ellos no

reemplazan las elecciones realizadas por de aplicaciones o

protocolos de capa superior, ni hacer impide el desarrollo

de los más avanzados mecanismos de selección de

direcciones. Los dos algoritmos comparten un contexto

común, incluyendo un mecanismo opcional para permitir a

los administradores de política que puede reemplazar la

configuración predeterminada comportamiento.

RFC 3493. Interfaz de socket básica para IPv6

El de facto estándar programa interfaz de aplicaciones

(API) para aplicaciones de TCP/IP es la interfaz "sockets".

Aunque esta API fue desarrollada para Unix en la década

de 1980 también se ha aplicado en una amplia variedad de

sistemas Unix no. Aplicaciones de TCP/IP escritas usando

los API de sockets han disfrutado en el pasado un alto

grado de portabilidad y quisiéramos que la misma

portabilidad con aplicaciones de IPv6. Pero cambios son

necesarios a la API de sockets para soporte IPv6 y este

memo describe estos cambios. Estos incluyen una nueva

estructura de dirección de socket para direcciones IPv6,

nuevas funciones de conversión de la dirección y algunas

nuevas opciones de socket. Estas extensiones están

diseñadas para proporcionar acceso a las funciones básicas

de IPv6 necesitan aplicaciones TCP y UDP, incluyendo la

multidifusión, al introducir un mínimo de cambios en el

sistema y proporciona compatibilidad completa para las

aplicaciones existentes de IPv4. Extensiones adicionales

para las funciones avanzadas de IPv6 (raw sockets y acceso

a los encabezados de extensión de IPv6) se definen en otro

documento. Este memorando proporciona información

para la comunidad de Internet.

RFC 3513. Arquitectura de direcciones para IPv6

Define la arquitectura de direccionamiento del IP protocol

versión 6 (IPv6). El documento incluye el modelo de

direccionamiento IPv6, representaciones de texto de

direcciones IPv6, definición de IPv6 direcciones de

unidifusión, direcciones anycast y direcciones de

multidifusión y direcciones requeridas del nodo IPv6

RFC 3542. API de sockets avanzada para IPv6

Proporciona interfaz de programa de aplicación (API) de

sockets para soportan aplicaciones IPv6 "avanzadas", como

un suplemento a una especificación independiente de ,

RFC 3493. Las aplicaciones previstas incluyen Ping,

Traceroute, daemons de encaminamiento y similares, que

normalmente uso raw tomas acceso IPv6 o campos de

encabezado ICMPv6. Este documento propone algunas

interfaces portátiles para aplicaciones que utilizan sockets

crudos de bajo IPv6. Hay otras características de IPv6 que

algunas aplicaciones de tendrá que acceder: la interfaz de

identificación (especificación de la interfaz de salida y

determinar la interfaz entrante de ), encabezados de

extensión de IPv6 y ruta de transmisión máximo

información de la unidad (MTU).

RFC 3587. Formato de direcciones de difusión única global

para IPv6

Define una asignación de direcciones IPv6 estructura que

incluye agregador de nivel superior (TLA) y siguiente nivel

agregador (NLA). Esto hace del documento RFC 2374 y

TLA/NLA estructura histórica.

RFC 3736. DHCPv6 sin estado

Servicio de protocolo de configuración dinámica de Host

apátrida para IPv6 (DHCPv6) es utilizado por los nodos

para obtener información de configuración, tan como las

direcciones de DNS recursiva nombre de servidores, que

no requieren el mantenimiento de cualquier estado

dinámico para clientes individuales. Un nodo que utiliza

DHCP apátrida debe haber obtenido sus direcciones IPv6 a

través de algún otro mecanismo, típicamente apátrida

abordar la configuración automática

RFC 4213. Mecanismos básicos de transición para IPv6

especifica mecanismos de compatibilidad de IPv4 que

pueden ser aplicación mediante IPv6 hosts y enrutadores.

Se especifican dos mecanismos, dual stack y túneles

configurados. Dual stack implica proporcionar

implementaciones completas de ambas versiones del

Protocolo de Internet (IPv4 y IPv6), y túneles configurados

proporciona un medio para llevar paquetes de IPv6 sobre

infraestructuras de enrutamiento IPv4 no modificadas

RFC 4291. Arquitectura de direcciones para IPv6

Especificación define la arquitectura de direccionamiento

del IP protocol versión 6 (IPv6). El documento incluye el

modelo de direccionamiento IPv6, representaciones de

texto de direcciones IPv6, definición de IPv6 direcciones de

unidifusión, direcciones anycast y direcciones de

multidifusión y direcciones requeridas del nodo IPv6

RFC 4443. ICMPv6

Describe el formato de un conjunto de mensajes de control

utilizado en ICMPv6 (Internet Control Message Protocol).

ICMPv6 es el Internet Control Message Protocol de

protocolo de Internet versión 6 (IPv6).

RFC Compliance

RFC 768 – UDP: Protocolo de datagrama de usuario

se define a poner a disposición una Datagrama modo de conmutación de

paquetes de comunicación en el ordenador Entorno de un conjunto

interconectado de redes de computadoras. Este Protocolo asume que el

Protocolo de Internet (IP) se utiliza como Protocolo subyacente.

RFC 783 – TFTP: TFTP es un protocolo muy simple que se usa para

transferir archivos. Se ha aplicado en Superior de la Internet User

Datagram protocolo (UDP o Datagram) por lo que Se puede utilizar para

mover archivos entre máquinas en diferentes redes

RFC 791 – IP

El Protocolo de Internet (IP) es un protocolo de capa de red (capa 3) en el

modelo OSI que contiene información de direccionamiento y cierta

información de control para permitir paquetes que se distribuyen en la

red. IP es el Protocolo de capa de red primaria en el protocolo TCP. Junto

con el Protocolo de Control de transmisión (TCP), IP representa el

corazón de los protocolos de Internet. IP es igualmente idóneo para

comunicaciones WAN y LAN.

RFC 792 – ICMP

Los mensajes ICMP son enviados mediante el encabezado IP básico. El primer octeto de la porción de datos del datagrama es un campo de tipo ICMP; el valor de este campo determina el formato de los datos restantes. Cualquier campo con la etiqueta "sin usar" está reservada para los posteriores extensiones y debe ser cero cuando envió, pero receptores no deben usar estos campos (excepto para incluirlas en la suma de comprobación).

RFC 793 – TCP

PROTOCOLO DE CONTROL DE TRANSMISIÓN El "protocolo de control de transmisión" ('Transmission Control Protocol', TCP) está pensado para ser utilizado como un protocolo 'host' a 'host' muy fiable entre miembros de redes de comunicación de computadoras por intercambio de paquetes y en un sistema interconectado de tales redes.

RFC 826 – ARP

La implementación de un protocolo P en un host emisor S decide, a través de un mecanismo de enrutamiento del protocolo P, que quiere transmitir a

un host de destino T localizado en algún lugar de un cable Ethernet 10Mbit. Para transmitir el paquete Ethernet se debe generar una dirección Ethernet de 48 bits. Las direcciones de hosts dentro de un protocolo P no son siempre compatibles con la correspondiente dirección Ethernet (siendo de diferentes longitudes o valores). Lo presentado aquí es un protocolo que permite la distribución dinámica de la información necesaria para construir tablas para traducir una dirección A en un espacio de direcciones de un protocolo P a direcciones Ethernet de 48 bits.

RFC 854 – Telnet

Especificaciones del protocolo Telnet

El protocolo Telnet es un protocolo de Internet estándar que permite

conectar terminales y aplicaciones en Internet. El protocolo proporciona

reglas básicas que permiten vincular a un cliente (sistema compuesto de

una pantalla y un teclado) con un intérprete de comandos (del lado del

servidor).

RFC 951 - Bootstrap Protocol (BOOTP)

Protocolo BOOTSTRAP (BOOTP) es un protocolo basado en UDP/IP que

permite a un host de arranque para configurarse dinámicamente y sin

supervisión de usuario. BOOTP proporciona un medio para notificar a

un host de su dirección IP, la dirección IP de un servidor de arranque y el

nombre de un archivo cargado en memoria y ejecutar. Otra información

de configuración, como la máscara de subred local, el desplazamiento de

hora local, las direcciones de los encaminadores predeterminados y las

direcciones de varios servidores de Internet también puede comunicarse

con un host mediante BOOTP.

RFC 959 – FTP

PROTOCOLO DE TRANSFERENCIA DE FICHEROS (FTP) promocionar el uso compartido de ficheros (programas y/o datos), 2) animar al uso indirecto o implícito (a través de programas) de servidores remotos, 3) hacer transparente al usuario las variaciones entre la forma de almacenar ficheros en diferentes ordenadores, y 4) transferir datos fiable y

eficientemente. El FTP, aunque puede ser utilizado directamente por un usuario en un terminal, está diseñado principalmete para ser usado por programas. Con esta especificación se intentan satisfacer las diversas necesidades de los usuarios de maxi-hosts, mini-hosts, estaciones de trabajo personales y TAC's con un diseño de protocolo simple y fácil de programar.

RFC 1112 - IP Multicast and IGMP

Este memo especifica las extensiones requeridas de una dirección IP de host aplicación que admiten la multidifusión IP, donde un "host" es cualquier host de internet o puerta de enlace que no sean las que actúan como enrutadores de multidifusión . Los algoritmos y protocolos utilizan dentro y entre enrutadores de multidifusión son transparentes a los hosts y serán especificadas en documentos separados. Este memo también no especifica cómo local multidifusión de red de se lleva a cabo para todos los tipos de red, aunque especificar la interfaz de servicio requerido a una red local de arbitraria y da una especificación Ethernet como un ejemplo de . Especificaciones para otros tipos de red será el tema de la del futuros memos.

RFC 1157 - SNMP v1

define un protocolo simple por que la administración información de un elemento de la red de puede ser inspeccionado o alterado por los usuarios de lógicamente remotos. En particular, junto con sus notas de compañero que describe la estructura de información de gestión junto con la base de información de gestión , estos documentos proporcionan un sistema de arquitectura de viable y simple para la gestión de Internet basada en TCP/IP y, en particular Internet.

La Junta de actividades de Internet recomienda que todos los IP y TCP implementaciones ser red manejable. Esto implica la aplicación de la MIB de

Internet (RFC-1156) y al menos uno de los dos recomienda protocolos de administración SNMP (RFC-1157) o CMOT (RFC-1095). Debe señalarse que, en este momento, SNMP es un completo estándar de Internet y CMOT es un proyecto estándar. Véase también el Host y Gateway RFC requisitos para información más específica sobre la aplicabilidad de de esta norma.

RFC 1166 - IP Addresses

Este memo es un informe sobre los números de red y números de

sistema autónomo en la comunidad de Internet.

RFC 1256 - Internet Control Message Protocol (ICMP)

Este documento especifica una extensión de la Internet Control

Message Protocol (ICMP) para permitir a hosts adjunta a la

multidifusión o difusión Redes para descubrir las direcciones IP de sus

vecinos routers.

RFC 1305 – NTP

Este documento describe el Network Time Protocol (NTP), especifica su estructura formal y resume la información útil para su aplicación . NTP proporciona los mecanismos para sincronizar la hora y coordinan la distribución de tiempo en una gran y diversa de internet funciona a velocidades de mundano a lightwave. Utiliza un diseño de retornables-tiempo en que una subred distribuida de servidores ubicados en un self- organización, configuración jerárquica-master-slave sincroniza a local de tiempo relojes dentro de la subred y a las normas de la hora nacional vía radio alambre o . Los servidores también pueden redistribuir el tiempo de referencia a través de algoritmos de enrutamiento locales y tiempo daemons.

RFC 1492 – TACACS

Un protocolo de Control de acceso, a veces llamado TACACS. Este

memorándum proporciona información para la comunidad de Internet.

No especifica un estándar de Internet. La distribución de este memo es

Ilimitada.

se describen las peticiones y las respuestas. Los siguientes Dos secciones

se describen dos formas diferentes de codificar la Protocolo.

Una petición / respuesta de pareja es la unidad básica de la interacción.

En este Par, el cliente envía una petición y el servidor responde con un

Respuesta. Todas las solicitudes deben ser reconocidos con una

respuesta. Este Requisito implica que todas las peticiones se le puede

negar, aunque es Probablemente inútil tratar de negar un "logout"

petición.

RFC 1493 - Bridge MIB

Este memo define una porción de la Base de información de administración (MIB) para uso con protocolos de administración de red en TCP/IP basado en internets. En particular define objetos para administrar puentes MAC basado en el estándar de IEEE 802.1X D-1990 entre red de área Local (LAN) segmentos. Se prevé para el soporte de puente transparente. Disposiciones también se hacen para que estos objetos se aplican a puentes conectados por subredes distintas segmentos LAN.

RFC 1542 - BOOTP extensions

aspectos e del protocolo BOOTP fueron bastante vagamente definidos en la especificación original de . En particular, sólo una descripción general fue proporcionada por el comportamiento de "Agentes de retransmisión BOOTP" (originalmente llamados agentes de reenvío BOOTP"). La descripción del comportamiento de cliente también sufrió en ciertas maneras. Este memo intenta aclarar y fortalecen la especificación en estas áreas. Debido a algunos errores introducidos en RFC 1532 en el proceso editorial, este memorando es reeditado como RFC 1542. Además, han surgido nuevos problemas ya que fue escrita la especificación original . Este memo también intenta abordar algunos de estos.

RFC 1643 - Ethernet Interface MIB

Este documento especifica un protocolo de pista de estándares de Internet para la comunidad de Internet de y la discusión de peticiones y sugerencias de mejora de . Consulte la edición actual de la "Internet normas de

protocolo oficiales" (STD 1) para el estado de normalización y estatus de este Protocolo. Distribución de esta memoria es ilimitada.

Esta sección sólo se aplica cuando este MIB se utiliza en conjunción con Los "antiguos" (es decir, antes de la RFC 1573) interfaz grupo. La relación entre un-como el interfaz ethernet y una interfaz En el contexto de la Internet-MIB estándar es de uno a uno. Como tal, El valor de un objeto ifIndex ejemplo se pueden usar directamente a Identificar las instancias correspondientes de los objetos definidos en el mismo.

RFC 1757 – RMON

Red de control remoto Control Management Information Base.Este

memo define una porción de la Base de información de administración

(MIB) para uso con protocolos de administración de red en TCP/IP-

based internets. En particular, define objetos para administrar la red

remota dispositivos de control.

Estándares Soportados

IEEE 802.1D Spanning Tree Protocol

el estándar de IEEE para bridges MAC (puentes MAC), que incluye bridging (técnica de reenvío de paquetes que usan los switches), el protocolo Spaning Tree y el funcionamiento de redes 802.11, entre otros.

También impide que los bucles que se forman cuando los puentes o los interruptores están interconectados a través de varias rutas.El algoritmo BPDU logra mediante el intercambio de mensajes con otros switches para detectar bucles y, a continuación, elimina el bucle por el cierre de puente seleccionado interfaces. Este algoritmo garantiza que hay una y sólo una ruta activa entre dos dispositivos de red.

EEE 802.1p CoS Prioritization

especificación permite a los conmutadores de capa 2 priorizar el tráfico y

realizar filtrado multicast dinámico. La especificación de priorización

funciona en la capa de estructura de media access control (MAC) (capa 2

del modelo OSI). El estándar 802.1P ofrece también disposiciones para

filtrar el tráfico de multidifusión para asegurarse de que no proliferen

sobre redes de conmutación 2 de capa.

IEEE 802.1Q VLAN

El protocolo IEEE 802.1Q, también conocido como dot1Q, fue un

proyecto del grupo de trabajo 802 de la IEEE para desarrollar un

mecanismo que permita a múltiples redes compartir de forma

transparente el mismo medio físico, sin problemas de interferencia entre

ellas (Trunking). Es también el nombre actual del estándar establecido en

este proyecto y se usa para definir el protocolo de encapsulamiento

usado para implementar este mecanismo en redes Ethernet. Todos los

dispositivos de interconexión que soportan VLAN deben seguir la norma

IEEE 802.1Q que especifica con detalle el funcionamiento y

administración de redes virtuales.

IEEE 802.1s

Redes de área de IEEE 802 local (LAN) de todos los tipos pueden

conectarse con puentes de media access control (MAC). Estándar IEEE

802.1Q especifica la operación de puentes de red de área local virtual

(VLAN), que soporte la operación VLAN dentro un IEEE 802 había

puenteado LAN. Este suplemento al estándar IEEE 802.1Q agrega la

instalación de puentes VLAN utilizar múltiples árboles de expansión,

para tráfico pertenecientes a diferentes VLAN para fluir sobre

potencialmente diferentes caminos dentro de la LAN virtual puenteada.

IEEE 802.1w

8021w de IEEE estándar también se basa en el algoritmo de Spanning

Tree; pero no es necesario volver a calcular el algoritmo de Spanning

Tree cuando se producen cambios en la topología. Tiene inteligencia

local para que sepa cómo mover un puerto desde el estado de bloqueo

para el estado de reenvío manteniendo una topología de árbol. Se ha

demostrado que 802.1w podría lograr un tiempo de conmutación por

error en 1-3 segundos. Es posible incluso en fracciones de segundos el

tiempo de conmutación por error para fallas de vínculo físico (por

ejemplo, la pérdida de señal). Debido al tiempo de failover rápido, IEEE

802.1w también se denomina algoritmo de árbol de expansión rápida y

Protocol (RSTP).

IEEE 802.1X

es una norma del IEEE para el control de acceso a red basada en puertos.

Es parte del grupo de protocolos IEEE 802 (IEEE 802.1). Permite la

autenticación de dispositivos conectados a un puerto LAN, estableciendo

una conexión punto a punto o previniendo el acceso por ese puerto si la

autenticación falla. Es utilizado en algunos puntos de acceso

inalámbricos cerrados y se basa en el protocolo de autenticación

extensible (EAP– RFC 2284). El RFC 2284 ha sido declarado obsoleto en

favor del RFC 3748.

IEEE 802.1ab (LLDP)

El Protocolo de descubrimiento de capa de enlace (LLDP) es un protocolo de capa de enlace de proveedor neutral en la Suite de protocolo de Internet utilizado por dispositivos de red para la publicidad de su identidad, sus capacidades y vecinos en una red de área local IEEE 802, principalmente con cable Ethernet.[1] El Protocolo se conoce formalmente por el IEEE como estación y Media Access Control conectividad descubrimiento especificados en el documento de estándares IEEE 802.1AB.LLDP realiza funciones similares a varios protocolos propietarios, como el Cisco Discovery Protocol, Protocolo de descubrimiento de extremo, Nortel Discovery Protocol (también conocido como SONMP) y descubrimiento de topología en capa Link (LLTD de Microsoft).

IEEE 802.3ad

El IEEE 802.3ad Link agrupación característica proporciona un método de agregar varios vínculos Ethernet en un único canal lógico. Esta característica ayuda a mejorar la rentabilidad de un dispositivo aumentando el ancho de banda acumulado sin necesidad de actualizaciones de hardware. Además,

IEEE 802.3ad Link agrupación proporciona una capacidad a disposición dinámicamente, administrar y supervisar varios enlaces agregados y permite interoperabilidad entre varios dispositivos Cisco y dispositivos de otros fabricantes.

Este documento describe cómo la IEEE 802.3ad Link agrupación característica aprovecha la infraestructura de EtherChannel dentro de software de Cisco IOS para administrar la agrupación de varios enlaces.

IEEE 802.3af

802.3af, también conocido como Power over Ethernet, define una manera

de construir equipos de abastecimiento de energía de Ethernet y

terminales de potencia. La especificación consiste en entrega de 48

voltios de corriente alterna sobre cableado de par trenzado no

apantallado. Funciona con planta de cable existente, incluyendo la

categoría 3, 5, 5e o 6; horizontal y cables de conexión; paneles de

interconexión; salidas; y la conexión de hardware, sin necesidad de

modificación.

IEEE 802.3ah (100BASE-X single/multimodefiber only)

Interfaces Ethernet capaces de funcionar a 100 Mbps o más rápidas en la

serie MX (excepto routers de la serie MX con MPCs), serie M (excepto

routers M5 y M10) y enrutadores serie t soportan IEEE 802.3ah estándar

de operación, administración y gestión (OAM). Puede configurar IEEE

802.3ah OAM en enlaces directos de Ethernet punto a punto o enlaces a

través de repetidores Ethernet. El IEEE 802.3ah estándar cumple con el

requisito para capacidades OAM como Ethernet pasa de ser

exclusivamente una tecnología empresarial a ser una tecnología WAN y

acceso, así como ser compatibles hacia atrás con tecnología Ethernet

existente. Sistema operativo Junos admite IEEE 802.3ah administración

de fallas de enlace.

IEEE 802.3x full duplex on 10BASE-T, 100BASE-TX,and 1000BASE-T

ports

Estándares IEEE para Local y redes de área metropolitana: suplementos

a Carrier Sense Multiple Access With método de detección de colisiones

(CSMA/CD) acceso y especificaciones de capa física - especificación

802.3 operación Full Duplex y especificación de capa física de 100 Mb/s

de operación en dos pares de categoría 3 O mejor equilibrado Cable de

par trenzado (100BASE-T2)

IEEE 802.3 10BASE-T specification

Cada interfaz de 10BaseT Ethernet permite un ancho de banda máximo

de 10 Mbps para un máximo ancho de banda agregado de 40 Mbps. Los

cuatro puertos funciona a velocidad de línea (cable).

Tabla 1-1 IEEE 802.3 y 10BaseT Ethernet versión 2 características físicas

Parámetro IEEE 802.3 Ethernet 10BaseT Ethernet

Velocidad de datos (Mbps)

10 10

Método de señalización

Baseband Baseband

Longitud de segmento máxima (m)

500 100 (UTP)

Medios de comunicación

cable coaxial de 50 ohmios (grueso)

Par de trenzado no apantallado (UTP)

Topología Bus Estrella

Tabla 1-2 muestra las especificaciones de cableado para la transmisión de 10 Mbps con cables UTP y FTP.

Parámetro RJ-45

Especificación de cable

Categoría 3 o categoría 5 UTP1 con AWG2 de 22 a 24

Longitud de segmento máxima

328 pies (100 m) para 10BaseT

Longitud máxima de 9.186 pies (2.800 m)

la red (con 4 repetidores)

IEEE 802.3u 100BASE-TX specification

Especificaciones y límites de conexión para la transmisión de 100 Mbps

la tabla a continuación enumera especificaciones de cable y los límites de conexión para la transmisión de 100 Mbps.

Parámetro RJ-45 MII SC-tipo

Especificación de cable

Categoría 52, UTP3, 22 a 24 AWG4

Categoría 3, r o 5, 150-ohm UTP o STP o fibra óptica multimodo

fiber62.5/125 de óptica multimodo de 62,5/125 multimodo fibra óptica

Longitud máxima del cable

- 0,5 m (1,64 pies.) (MII a MII cable5)

-

longitud de segmento maximum

100 m (328 pies) para 100BaseTX

1 m (3.28 pies)6 o 400 m (1312 pies) para 100BaseFX

100 m (328 ft).

Longitud máxima de la red

200 metros (656 pies)6 (con un repetidor)

- 200 metros (656 pies)6 (con un repetidor)

IEEE 802.3ab 1000BASE-T specification

1000BASE-T (también conocido como IEEE 802.3ab) es un estándar para gigabit Ethernet sobre cableado de cobre. Cada segmento de red 1000BASE-T puede ser una longitud máxima de 100 metros (328 pies) y se debe utilizar cable de categoría 5 o superior (incluyendo Cat 5e y Cat 6).

* También conocido como IEEE 802.3ab, esto es un estándar para Gigabit Ethernet sobre cableado de cobre, pero requiere cable de categoría 5 (Cat 5) como mínimo.

La especificación para Ethernet Gigabit prevé una serie de requisitos que deben cumplir. Estos pueden resumirse como los puntos siguientes:

* prever la mitad y operación full duplex a velocidades de 1000 Mbps.

* Utilice los formatos de frame Ethernet 802,3.

* Use el método de acceso CSMA/CD con soporte para un repetidor por dominio de colisión.

* Proporcionar compatibilidad con tecnologías 10BASE-T y 100BASE-T.