Conmutador Core
Transcript of Conmutador Core
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.