RIPng para IPv6

Estado de esta nota

Este documento especifica un protocolo de seguimiento de estándares de Internet para

Comunidad de Internet, y solicita discusión y sugerencias para mejoras Consulte la
edición actual de "Internet
Normas oficiales de protocolo "(STD 1) para el estado de estandarización y estado de
este protocolo. La distribución de este memo es ilimitada.

Resumen

Este documento especifica un protocolo de enrutamiento para un internet IPv6. Eso se

basa en protocolos y algoritmos actualmente en uso generalizado en el Internet IPv4.

Esta especificación representa el cambio mínimo al enrutamiento

Protocolo de información (RIP), como se especifica en RFC 1058 [1] y RFC 1723[ 2 ],
necesarios para la operación sobre IPv6 [ 3 ].

Agradecimientos

Este documento es una versión modificada de RFC 1058 , escrita por Chuck Hedrick [ 1
]. Las modificaciones reflejan las mejoras de RIP-2 e IPv6, pero la redacción original
es suya.

Nos gustaría agradecer a Dennis Ferguson y Thomas Narten por sus comentarios.

Tabla de contenido

1 . Introducción . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Fundamentos teóricos. . . . . . . . . . . . . . . . . 3
1.2 Limitaciones del Protocolo. . . . . . . . . . . . . . . . 3
2 . Especificación de protocolo. . . . . . . . . . . . . . . . . 4
2.1 Formato del mensaje. . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Próximo salto. . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Consideraciones de direccionamiento. . . . . . . . . . . . . . . . . 8
2.3 Temporizadores. . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 Procesamiento de entrada. . . . . . . . . . . . . . . . . . . . . . 10
2.4.1 Mensajes de solicitud. . . . . . . . . . . . . . . . . . . . . 10
2.4.2 Mensajes de respuesta. . . . . . . . . . . . . . . . . . . . 11

2.5 Procesamiento de salida. . . . . . . . . . . . . . . . . . . . . 14

2.5.1 Actualizaciones activadas. . . . . . . . . . . . . . . . . . . . 14
2.5.2 Generación de mensajes de respuesta. . . . . . . . . . . . . . . 15
2.6 Horizonte dividido. . . . . . . . . . . . . . . . . . . . . . . 16
3 . Funciones de control. . . . . . . . . . . . . . . . . . . . . . 17
4 . Consideraciones de Seguridad. . . . . . . . . . . . . . . . . . . . 18
referencias. . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Direcciones de los autores. . . . . . . . . . . . . . . . . . . . . . . . 19

1 . Introducción

Este memo describe un protocolo en una serie de protocolos de enrutamiento basado en

el algoritmo Bellman-Ford (o vector de distancia). El algoritmo se ha utilizado para
enrutar cálculos en redes de computadoras desde los primeros días de ARPANET. Los
formatos de paquetes particulares y el protocolo descrito aquí se basan en el programa
"enrutado", que se incluye con la distribución Berkeley de Unix.

En una red internacional, como Internet, es muy improbable que se use un solo
protocolo de enrutamiento para toda la red. Por el contrario, la red se organizará como
una colección de Sistemas autónomos (AS), cada uno de los cuales, en general, será
administrado por una sola entidad. Cada AS tendrá su propia ruta tecnología, que puede
diferir entre los AS. El protocolo de enrutamiento utilizado
 dentro de un AS se conoce como Protocolo de puerta de enlace interior (IGP). Un se
usa un protocolo separado, llamado Protocolo de puerta de enlace exterior (EGP) para
transferir información de enrutamiento entre los AS.

RIPng fue diseñado para trabajar como IGP en AS de tamaño moderado. No es para uso en
ambientes mas complejos. Para obtener información sobre el contexto en qué versión RIP
1 (RIP-1) se espera que se ajuste, ver Braden y Postel
[ 6 ]

RIPng es uno de una clase de algoritmos conocidos como Vector de distancia

algoritmos La primera descripción de esta clase de algoritmos.
conocido por el autor está en Ford y Fulkerson [ 8 ]. Debido a esto,
a veces se los conoce como algoritmos Ford-Fulkerson. El termino
Bellman-Ford también se utiliza, y se deriva del hecho de que el
formulación se basa en la ecuación de Bellman [ 4 ]. La presentación en
Este documento está estrechamente basado en [ 5 ]. Este documento contiene un
especificación de protocolo Para una introducción a las matemáticas de
algoritmos de enrutamiento, ver [ 1 ]. Los algoritmos básicos utilizados por este
protocolo se utilizaron en el enrutamiento informático ya en 1969 en el
ARPANET Sin embargo, la ascendencia específica de este protocolo está dentro de
Los protocolos de red Xerox. Los protocolos PUP [ 7 ] usaron el Gateway
Protocolo de información para intercambiar información de enrutamiento. Un poco
Se adoptó una versión actualizada de este protocolo para la red Xerox
Arquitectura de sistemas (XNS), con el nombre Información de enrutamiento
Protocolo [ 9 ]. Enrutado de Berkeley es en gran medida lo mismo que el enrutamiento

Protocolo de información, con direcciones XNS reemplazadas por una más general
formato de dirección capaz de manejar IPv4 y otros tipos de dirección,
y con actualizaciones de enrutamiento limitadas a una cada 30 segundos. Porque
esta similitud, el término Protocolo de información de enrutamiento (o simplemente
RIP)
se utiliza para referirse tanto al protocolo XNS como al protocolo utilizado por
enrutado

1.1 Fundamentos teóricos

Una introducción a la teoría y las matemáticas detrás del vector de distancia

Los protocolos se proporcionan en [ 1 ]. No ha sido incorporado en este
documento en aras de la brevedad.

1.2 Limitaciones del protocolo

Este protocolo no resuelve todos los posibles problemas de enrutamiento. Como

mencionado anteriormente, está destinado principalmente para su uso como IGP en
redes de tamaño moderado. Además, los siguientes específicos
Se mencionan limitaciones:

- El protocolo está limitado a redes cuya ruta más larga (la

diámetro de la red) es de 15 saltos. Los diseñadores creen que el
El diseño del protocolo básico es inapropiado para redes más grandes. Nota
que esta declaración del límite supone que se usa un costo de 1
para cada red Esta es la forma en que normalmente se configura RIPng.
Si el administrador del sistema elige usar costos mayores,
límite de 15 puede convertirse fácilmente en un problema.

- El protocolo depende de "contar hasta el infinito" para resolver ciertos

situaciones inusuales (ver sección 2.2 en [ 1 ]). Si el sistema de
las redes tienen varios cientos de redes y se formó un bucle de enrutamiento
involucrando a todos ellos, la resolución del bucle requeriría
ya sea mucho tiempo (si la frecuencia de las actualizaciones de enrutamiento fuera
limitada)
o ancho de banda (si se enviaron actualizaciones cada vez que se detectaron
cambios).
Tal bucle consumiría una gran cantidad de ancho de banda de red
 antes de que se corrigiera el bucle. Creemos que en casos realistas,
Esto no será un problema, excepto en líneas lentas. Incluso entonces, el
El problema será bastante inusual, ya que se toman varias precauciones
eso debería evitar estos problemas en la mayoría de los casos.

- Este protocolo utiliza "métricas" fijas para comparar rutas alternativas.

No es apropiado para situaciones en las que se deben elegir rutas
basado en parámetros en tiempo real como un retraso medido, confiabilidad,
o carga. Las extensiones obvias para permitir métricas de este tipo son
es probable que presente inestabilidades del tipo que el protocolo es
No diseñado para manejar.

2 . Especificación de protocolo

RIPng está diseñado para permitir que los enrutadores intercambien información por
rutas de computación a través de una red basada en IPv6. RIPng es un protocolo de
distancia vectorial, como se describe en [ 1 ]. RIPng debe implementarse solo en
enrutadores; IPv6 proporciona otros mecanismos para el descubrimiento de enrutadores
[ 10 ] Se supone que cualquier enrutador que use RIPng tiene interfaces para una o
más redes, de lo contrario no es realmente un enrutador. Estos son referido como sus
redes conectadas directamente. El protocolo se basa sobre el acceso a cierta
información sobre cada una de estas redes.
El más importante de los cuales es su métrica. La métrica RIPng de una red es un
entero entre 1 y 15, inclusive. Se establece de alguna manera no especificado en este
protocolo; sin embargo, dado el límite máximo de ruta de 15, generalmente se usa un
valor de 1. Las implementaciones deberían permitir al administrador del sistema para
establecer la métrica de cada red.
Además de la métrica, cada red tendrá un destino IPv6 prefijo de dirección y
longitud del prefijo asociado a él. Estos deben ser
establecido por el administrador del sistema de una manera no especificada en este
protocolo.

Se supone que cada enrutador que implementa RIPng tiene una tabla de enrutamiento.
Esta tabla tiene una entrada para cada destino accesible
en todo el sistema operando RIPng. Cada entrada contiene al menos
la siguiente información:

- El prefijo IPv6 del destino.

- Una métrica, que representa el costo total de obtener un datagrama desde el

enrutador a ese destino. Esta métrica es la suma de costos asociados con las redes que
se atravesarían para obtener al destino

- La dirección IPv6 del siguiente enrutador a lo largo de la ruta al

destino (es decir, el próximo salto). Si el destino está en uno de
las redes conectadas directamente, este elemento no es necesario.

- Una bandera para indicar que la información sobre la ruta ha cambiado

recientemente. Esto se denominará "bandera de cambio de ruta".

- Varios temporizadores asociados con la ruta. Vea la sección 2.3 para más detalles
sobre temporizadores.

Las entradas para las redes conectadas directamente son configuradas por enrutador
utilizando la información recopilada por medios no especificados en este protocolo. La
métrica para una red conectada directamente se establece en costo de esa red. Como se
mencionó, 1 es el costo habitual. En eso caso, la métrica RIPng se reduce a un simple
conteo de saltos. Mas complejo las métricas se pueden usar cuando es deseable mostrar
preferencia por algunos
redes sobre otras (por ejemplo, para indicar diferencias en el ancho de banda o
confiabilidad).

Los implementadores también pueden optar por permitir que el administrador del
sistema ingrese rutas adicionales. Lo más probable es que sean rutas a hosts o redes
fuera del alcance del sistema de enrutamiento. Son referido como "rutas estáticas".
Entradas para destinos que no sean estos iniciales son añadidos y actualizados por los
algoritmos descritos en las siguientes secciones.

Para que el protocolo proporcione información completa sobre el enrutamiento, cada

enrutador en el AS debe participar en el protocolo. En casos donde se utilizan
múltiples IGP, debe haber al menos un enrutador que puede filtrar información de
enrutamiento entre los protocolos.

2.1 Formato del mensaje

RIPng es un protocolo basado en UDP. Cada enrutador que usa RIPng tiene un proceso
de enrutamiento que envía y recibe datagramas en el número de puerto UDP 521, el puerto
RIPng. Todas las comunicaciones destinadas a otro
El proceso RIPng del enrutador se envía al puerto RIPng. Todo el enrutamiento Los
mensajes de actualización se envían desde el puerto RIPng. Enrutamiento no solicitado
los mensajes de actualización tienen tanto el puerto de origen como el de destino igual
a El puerto RIPng.

Los enviados en respuesta a una solicitud se envían al puerto de donde vino la

solicitud. Se pueden enviar consultas específicas desde puertos distintos del puerto
RIPng, pero deben dirigirse al Puerto RIPng en la máquina de destino.

El formato del paquete RIPng es:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| command (1) | version (1) | must be zero (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Route Table Entry 1 (20) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ... ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Route Table Entry N (20) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

donde cada entrada de tabla de ruta (RTE) tiene el siguiente formato:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ IPv6 prefix (16) ~
| |
+---------------------------------------------------------------+
| route tag (2) | prefix len (1)| metric (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

El número máximo de RTE se define a continuación.

Los tamaños de campo se dan en octetos. A menos que se especifique lo contrario, los
campos contienen enteros binarios, en orden de bytes de red, con la mayoría octeto
significativo primero (big-endian). Cada marca representa uno poco.

Cada mensaje contiene un encabezado RIPng que consiste en un comando y Un número de

versión. Este documento describe la versión 1 del protocolo (ver sección 2.4 ). El
campo de comando se usa para especificar el propósito de este mensaje Los comandos
implementados en la versión 1 son:
 1 - solicitud Una solicitud para que el sistema de respuesta envíe todo o parte de
su tabla de enrutamiento.

2 - respuesta Un mensaje que contiene todo o parte del remitente

tabla de ruteo. Este mensaje puede ser enviado en respuesta a una
solicitud, o puede ser una ruta no solicitada actualización generada por el remitente.

Para cada uno de estos tipos de mensajes, el resto del datagrama

contiene una lista de RTE. Cada RTE en esta lista contiene un
prefijo de destino, el número de bits significativos en el prefijo y El costo para
llegar a ese destino (métrica).

El prefijo de destino es el prefijo de dirección IPv6 de 128 bits habitual

almacenado como 16 octetos en orden de bytes de red.

El campo de etiqueta de ruta es un atributo asignado a una ruta que debe ser
conservado y revertido con una ruta. El uso previsto de la
la etiqueta de ruta es proporcionar un método para separar RIPng "interno" rutas
(rutas para redes dentro del dominio de enrutamiento RIPng) desde rutas RIPng
"externas", que pueden haberse importado de un EGP u otro IGP

Los enrutadores que admiten protocolos distintos de RIPng deben ser configurables para
permitir que la etiqueta de ruta se configure para rutas importadas de diferentes
fuentes
Por ejemplo, las rutas importadas desde un EGP deberían poder tener su etiqueta de ruta
establecida en un valor arbitrario, o al menos al número del Sistema Autónomo desde el
cual las rutas fueron aprendidas

Otros usos de la etiqueta de ruta son válidos, siempre que todos los enrutadores El
dominio RIPng lo usa constantemente.

El campo de longitud del prefijo es la longitud en bits de la parte significativa

del prefijo (un valor entre 0 y 128 inclusive) a partir de la izquierda del prefijo.

El campo métrico contiene un valor entre 1 y 15 inclusive,

especificando la métrica actual para el destino; o el valor 16
(infinito), que indica que no se puede llegar al destino.

El tamaño máximo del datagrama está limitado por la MTU del medio sobre cuál es el
protocolo que se está utilizando. Desde una actualización RIPng no solicitada nunca se
propaga a través de un enrutador, no hay peligro de una MTU discordancia. La
determinación del número de RTE que se pueden poner en un mensaje dado es una función
de la MTU del medio, el número de octetos de información de encabezado que preceden al
mensaje RIPng, el tamaño del encabezado RIPng y el tamaño de un RTE. La formula es:

+- -+
| MTU - sizeof(IPv6_hdrs) - UDP_hdrlen - RIPng_hdrlen |
#RTEs = INT | --------------------------------------------------- |
| RTE_size |
+- -+

2.1.1 Próximo salto

RIPng proporciona la capacidad de especificar el próximo salto inmediato IPv6

dirección a qué paquetes a un destino especificado por una tabla de ruta
La entrada (RTE) debe reenviarse de la misma manera que RIP-2 [ 2 ].
En RIP-2, cada entrada de la tabla de ruta tiene un campo de salto siguiente.
Incluyendo el campo de siguiente salto para cada RTE en RIPng casi duplicaría el tamaño
del RTE. Por lo tanto, en RIPng, el siguiente salto se especifica mediante un especial
RTE y se aplica a todos los RTE de dirección que siguen al RTE del siguiente salto
hasta el final del mensaje o hasta que otro próximo salto RTE es encontrado

Un RTE del siguiente salto se identifica por un valor de 0xFF en el campo métrico
de un RTE. El campo de prefijo especifica la dirección IPv6 del siguiente salto.
La etiqueta de ruta y la longitud del prefijo en el RTE del siguiente salto se debe
establecer a cero en el envío e ignorarse en la recepción.

La entrada de tabla de ruta (RTE) del siguiente salto tiene el siguiente formato:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ IPv6 next hop address (16) ~
| |
+---------------------------------------------------------------+
| must be zero (2) |must be zero(1)| 0xFF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Especificar un valor de 0: 0: 0: 0: 0: 0: 0: 0 en el campo de prefijo RTE del salto

siguiente indica que la siguiente dirección de salto debe ser la originadora
del anuncio RIPng. Una dirección especificada como próximo salto debe
ser una dirección de enlace local.

El propósito del próximo salto RTE es eliminar los paquetes que se enrutan
a través de saltos adicionales en el sistema. Es particularmente útil cuando
RIPng no se ejecuta en todos los enrutadores de una red. Tenga en cuenta que
El siguiente salto RTE es "asesor". Es decir, si la información proporcionada es
ignorada, una ruta posiblemente subóptima, pero absolutamente válida, puede ser
tomado. Si la dirección de siguiente salto recibida no es una dirección local de
enlace debe tratarse como 0: 0: 0: 0: 0: 0: 0: 0.

2.2 Consideraciones de direccionamiento

La distinción entre red, subred y rutas de host no necesitan ser hechos para RIPng
porque un prefijo de dirección IPv6 no es ambiguo.

Cualquier prefijo con una longitud de prefijo de cero se utiliza para designar un
Ruta por defecto. Se sugiere que el prefijo 0: 0: 0: 0: 0: 0: 0: 0 sea usado al
especificar la ruta predeterminada, aunque el prefijo es esencialmente ignorado. Se
utiliza una ruta predeterminada cuando no es conveniente enumerar todas las redes
posibles en las actualizaciones de RIPng, y cuando uno o más enrutadores del sistema
están preparados para manejar el tráfico a las redes que no están explícitamente
enumeradas. Estos "predeterminados enrutadores "usan la ruta predeterminada como ruta
para todos los datagramas para los cuales no tienen una ruta explícita.
La decisión de cómo se convierte un enrutador en un enrutador predeterminado (es decir,
cómo se crea una entrada de ruta predeterminada) se deja al implementador.
En general, el administrador del sistema será provisto de una forma de especificar qué
enrutadores deben crear y anunciar entradas de ruta predeterminadas. Si se utiliza este
mecanismo, la implementación debe permitir al administrador de la red elegir la métrica
asociada con el anuncio de ruta predeterminado.
Esto permitirá establecer una precedencia entre múltiples rutas predeterminadas
Las entradas de ruta predeterminadas son manejadas por RIPng exactamente de la misma
manera que cualquier otro prefijo de destino.
Los administradores de sistema deben asegurarse de que las rutas predeterminadas no se
propaguen más allá de lo previsto. En general, cada AS tiene su propio enrutador
predeterminado preferido. Por lo tanto, las rutas predeterminadas deberían generalmente
no salir del límite de un AS. Los mecanismos para hacer cumplir esta restricción no se
especifican en este documento.

2.3 Temporizadores

Esta sección describe todos los eventos que son activados por temporizadores.

Cada 30 segundos, el proceso RIPng se activa para enviar un Mensaje de respuesta no

solicitado, que contiene la tabla de enrutamiento completa(vea la sección 2.6 en Split
Horizon), a cada enrutador vecino.
 Cuando hay muchos enrutadores en una sola red, hay una tendencia para que se
sincronicen entre sí de modo que todos emitan actualizaciones al mismo tiempo. Esto
puede suceder cada 30 segundos

El temporizador se ve afectado por la carga de procesamiento en el sistema.

No es deseable que los mensajes de actualización se sincronicen, ya que puede conducir
a colisiones innecesarias en las redes de transmisión (ver [ 13 ]
para más detalles).

Por lo tanto, se requieren implementaciones para tomar una de dos precauciones:

- Las actualizaciones de 30 segundos son activadas por un reloj cuya frecuencia no

es afectado por la carga del sistema o el tiempo requerido para reparar el temporizador
de actualización anterior.

- El temporizador de 30 segundos se compensa con un pequeño tiempo aleatorio (+/- 0

a 15 segundos) cada vez que se establece. El desplazamiento se deriva de: 0.5 * el
período de actualización (es decir, 30).

Hay dos temporizadores asociados con cada ruta, un "tiempo de espera" y un

"tiempo de recolección de basura". Al expirar el tiempo de espera, la ruta
ya no es válido; sin embargo, se retiene en la tabla de enrutamiento por
poco tiempo para que los vecinos puedan ser notificados de que la ruta se ha
descartado. Al expirar el temporizador de recolección de basura, la ruta finalmente se
elimina de la tabla de enrutamiento.

El tiempo de espera se inicializa cuando se establece una ruta y cada vez que se
recibe un mensaje de actualización para la ruta.
Si transcurren 180 segundos desde la última vez que se inicializó el tiempo de espera,
la ruta se considera que ha expirado y el proceso de eliminación descrito a
continuación comienza para esa ruta esa ruta.

Las eliminaciones pueden ocurrir por una de dos razones: el tiempo de espera caduca o
la métrica se establece en 16 debido a una actualización recibida del enrutador actual
(consulte la sección 2.4.2 para una discusión sobre el procesamiento actualizaciones de
otros enrutadores). En cualquier caso, suceden los siguientes eventos:

- El temporizador de recolección de basura se establece en 120 segundos.

- La métrica para la ruta se establece en 16 (infinito). Esto provoca la

ruta a ser eliminada del servicio.

- La bandera de cambio de ruta es para indicar que esta entrada ha sido

cambiado

- El proceso de salida se señala para activar una respuesta.

Hasta que caduque el temporizador de recolección de basura, la ruta se incluye en

todas las actualizaciones enviadas por este enrutador. Cuando el temporizador de
recolección de basura caduca, la ruta se elimina de la tabla de enrutamiento.

Si se establece una nueva ruta a esta red mientras el temporizador de recolección de

basura se está ejecutando, la nueva ruta reemplazará la que está a punto de ser
eliminado. En este caso, el temporizador de recolección de basura debe ser despejado

Las actualizaciones activadas también usan un temporizador pequeño; sin embargo,

esto es lo mejor descrito en la sección 2.5.1 .

2.4 Procesamiento de entrada

Esta sección describirá el manejo de los datagramas recibidos en elpuerto RIPng. El

procesamiento dependerá del valor en el comandocampo. La versión 1 solo admite dos
comandos: Solicitud y Respuesta.

2.4.1 Mensajes de solicitud

 Una solicitud se utiliza para solicitar una respuesta que contenga todo o parte de
un tabla de enrutamiento del enrutador.
Normalmente, las solicitudes se envían como multidifusión, desde el puerto RIPng, por
enrutadores que acaban de aparecer y son tratando de completar sus tablas de
enrutamiento lo más rápido posible.
Sin embargo, puede haber situaciones (por ejemplo, monitoreo de enrutadores) dondese
necesita una tabla de enrutamiento de un solo enrutador. En este caso, la solicitud
debe enviarse directamente a ese enrutador desde un puerto UDP que no sea el puerto
RIPng.

Si se recibe dicha solicitud, el enrutador responde directamente a la dirección y al

puerto del solicitante con una dirección de origen globalmente válida ya que el
solicitante no puede residir en la red conectada directamente.

La solicitud se procesa entrada por entrada. Si no hay entradas, no se da respuesta.

Hay un caso especial. Si hay exactamente una entrada en la solicitud, y tiene un
prefijo de destino de cero, una longitud del prefijo de cero y una métrica de infinito
(es decir, 16), entonces esto es una solicitud para enviar toda la tabla de
enrutamiento. En ese caso, una llamada se realiza en el proceso de salida para enviar
la tabla de enrutamiento a dirección / puerto solicitante. A excepción de este caso
especial, el procesamiento es bastante sencillo. Examine la lista de RTE en la
Solicitud uno por uno.

Para cada entrada, busque el destino en la base de datos del enrutador y, si hay una
ruta, coloque la métrica de esa ruta en el campo métrico del RTE. Si no hay una ruta
explícita al destino especificado, poner infinito en el campo métrico. Una vez que
todas las entradas se han completado, cambie el comando de Solicitud a Respuesta y
envíe el datagrama de vuelta al solicitante.

Tenga en cuenta que existe una diferencia en el manejo de métricas para solicitudes de
tabla completa. Si la solicitud es para un enrutamiento de tabla completa, se realiza
el procesamiento de salida normal, incluido Split Horizon (ver sección 2.6 en Split
Horizon). Si la solicitud es para entradas específicas, se buscan en la tabla de
enrutamiento y la información se devuelve como es; no se realiza el procesamiento de
Split Horizon. La razón para esta distinción es la expectativa de que estas solicitudes
probablemente que se utilice para diferentes propósitos. Cuando un enrutador llega por
primera vez, realiza una solicitud de multidifusión en cada red conectada que solicita
una tabla de enrutamiento completa. Se supone que estas tablas de rutas completas se
utilizarán para actualizar la tabla de enrutamiento del solicitante.
Por esta razón, Split Horizon debe hacerse. Se supone además que la solicitud de redes
específicas se realiza solo mediante software de diagnóstico, y no se usa para
enrutamiento. En este caso, el solicitante querría saber el contenido exacto de la
tabla de enrutamiento y no desearía cualquier información oculta o modificada.

2.4.2 Mensajes de respuesta

Se puede recibir una respuesta por una de varias razones diferentes:

- respuesta a una consulta específica

- actualización periódica (respuesta no solicitada)
- actualización activada causada por un cambio de ruta

El procesamiento es el mismo sin importar por qué se generó la Respuesta.

Debido a que el procesamiento de una Respuesta puede actualizar la tabla enrutamiento

del enrutador, la respuesta debe verificarse cuidadosamente para verificar su validez.
La respuesta debe ignorarse si no es del puerto RIPng. La dirección de origen IPv6 del
datagrama debe verificarse para ver si el datagrama es de un vecino válido; la fuente
del datagrama debe ser una dirección de enlace local. También vale la pena verificar si
la respuesta es de una de las direcciones del enrutador. Las interfaces en las redes de
difusión pueden recibir copias de su propia multidifusión inmediatamente. Si un
enrutador procesa su propia salida como nueva entrada, es probable que haya confusión,
y tales datagramas deben ignorarse. Como una verificación adicional, los anuncios
periódicos deben tener su conteo de saltos configurado en 255, y entrantes, paquetes de
multidifusión enviados desde el puerto RIPng(es decir, publicidad periódica o paquetes
de actualización activados) deben ser examinado para asegurar que el conteo de saltos
es 255. Esto absolutamente garantiza que un paquete es de un vecino, porque cualquier
nodo intermedio habría disminuido el conteo de saltos. Las consultas y sus respuestas
aún pueden cruzar nodos intermedios y, por lo tanto, no requieren que se realice la
prueba de conteo de saltos.

Una vez que el datagrama en su conjunto ha sido validado, procese los RTE en la
respuesta uno por uno. Nuevamente, comience haciendo validación. Las métricas
incorrectas y otros errores de formato generalmente indican mal comportamientos vecinos
y probablemente debería ser llevado a la atención del administrador, Por ejemplo, si la
métrica es mayor que infinito, ignore la entrada, pero registre el evento. Las pruebas
de validación básica son:

- Es válido el prefijo de destino (por ejemplo, no es un prefijo de multidifusión y

no una dirección de enlace local) Una dirección de enlace local nunca debe ser presente
en un RTE.
- Es válida la longitud del prefijo (es decir, entre 0 y 128, inclusive)
- Es la métrica válida (es decir, entre 1 y 16, inclusive)

Si alguna verificación falla, ignore esa entrada y continúe con la siguiente.

Nuevamente, registrar el error es probablemente una buena idea.
Una vez que se haya validado la entrada, actualice la métrica agregando el costo de la
red en la que llegó el mensaje. Si el resultado es mayor que infinito, usa infinito. Es
decir,
métrica = MIN (métrica + costo, infinito)

Ahora, verifique si ya existe una ruta explícita para el prefijo de destino. Si no

existe tal ruta, agregue esta ruta a la tabla de enrutamiento, a menos que la métrica
sea infinita (no tiene sentido agregar una ruta que no se puede usar). Agregar una ruta
a la tabla de enrutamiento consiste en:

- Establecer el prefijo de destino y la longitud para aquellos en el RTE.

- Establecer la métrica a la métrica recién calculada (como se describe encima).

- Configure la dirección del siguiente salto para que sea la dirección del enrutador
del que proviene el datagrama o la dirección del siguiente salto especificada por un
RTE del siguiente salto.

- Inicializar el tiempo de espera para la ruta. Si la recolección de basura el

temporizador se está ejecutando para esta ruta, deténgalo (consulte la sección 2.3 para
obtener una discusión de los temporizadores).

- Establecer la bandera de cambio de ruta.

- Señale el proceso de salida para activar una actualización (consulte la sección 2.5).

Si hay una ruta existente, compare la dirección del próximo salto con la dirección del
enrutador del que proviene el datagrama. Si este datagrama es del mismo enrutador que
la ruta existente, reinicialice el tiempo de espera. Luego, compara las métricas. Si el
datagrama es del mismo enrutador que la ruta existente, y la nueva métrica es diferente
que el viejo; o, si la nueva métrica es más baja que la anterior; hacer las siguientes
acciones:

- Adopta la ruta del datagrama. Es decir, coloque la nueva métrica, y ajuste la

dirección del siguiente salto (si es necesario).

- Establezca el indicador de cambio de ruta y señale el proceso de salida para que se

active una actualización.

- Si la nueva métrica es infinita, inicie el proceso de eliminación (descrito

anteriormente); de lo contrario, reinicie el tiempo de espera.

Si la nueva métrica es infinita, el proceso de eliminación comienza para la ruta, que

ya no se usa para enrutar paquetes. Tenga en cuenta que el proceso de eliminación solo
se inicia cuando la métrica se establece por primera vez en infinito. Si la métrica ya
era infinita, entonces no se inicia un proceso de eliminación.
Si la nueva métrica es la misma que la anterior, es más sencillo no hacer nada más (más
allá de reiniciar el tiempo de espera, como se especifica encima); pero hay una
heurística que podría aplicarse. Normalmente, no tiene sentido reemplazar una ruta si
la nueva ruta tiene la misma métrica como la ruta existente; esto haría que la ruta
rebotara de ida y vuelta, lo que generaría un número intolerable de actualizaciones
activadas.
Sin embargo, si la ruta existente muestra señales de tiempo de espera excedido, puede
ser mejor cambiar a una ruta alternativa igualmente buena de inmediato, en lugar de
esperar a que suceda el tiempo de espera. Por lo tanto, si la nueva métrica es la misma
que la anterior, examinar el tiempo de espera para la ruta existente. Si es al menos a
mitad de camino hasta el punto de vencimiento, cambie a la nueva ruta. Esta La
heurística es opcional, pero muy recomendable.
Cualquier entrada que falle estas pruebas se ignora, ya que no es mejor que la ruta
actual.

2.5 Procesamiento de salida

Esta sección describe el procesamiento utilizado para crear mensajes de respuesta que
contienen todo o parte de la tabla de enrutamiento. Este procesamiento se puede activar
de cualquiera de las siguientes maneras:

- Por procesamiento de entrada, cuando se recibe una solicitud. En este caso, la

respuesta se envía a un solo destino (es decir, la dirección de unidifusión del
solicitante).

- Por la actualización de enrutamiento regular. Cada 30 segundos, una respuesta que

contiene toda la tabla de enrutamiento se envía a cada vecino enrutador

- Por actualizaciones activadas. Cada vez que se cambia la métrica de una ruta, se
activa una actualización.

El procesamiento especial requerido para una Solicitud se describe en la sección 2.4.1.

Cuando se debe enviar una Respuesta a todos los vecinos (es decir, un mensaje regular o
actualización activada), un mensaje de respuesta es multidifusión al grupo de
multidifusión FF02 :: 9, el grupo de multidifusión all-rip-routers, en todos las redes
conectadas que admiten transmisión o son enlaces punto a punto. RIPng maneja enlaces
punto a punto al igual que los enlaces de multidifusión como la multidifusión se puede
proporcionar trivialmente en dichos enlaces. Por lo tanto, se prepara una respuesta
para cada red conectada directamente y se envía al grupo de multidifusión de todos los
enrutadores. En la mayoría de los casos, esto llega a todos los enrutadores vecinos.
Sin embargo, hay algunos casos en los que esto puede no ser lo suficientemente bueno.
Esto puede involucrar una red que no es red de transmisión (por ejemplo, ARPANET), o
una situación que involucra tontos enrutadores.
En tales casos, puede ser necesario especificar una lista de enrutadores vecinos y
enviar un datagrama a cada uno explícitamente. Se deja al implementador determinar si
se necesita un mecanismo y definir cómo se especifica la lista.

2.5.1 Actualizaciones activadas

Las actualizaciones activadas requieren un manejo especial por dos razones.

Primero, la experiencia muestra que las actualizaciones activadas pueden causar cargas
excesivas en redes con capacidad limitada o redes con muchos enrutadores. Por lo tanto,
el protocolo requiere que los implementadores incluyan disposiciones para limitar la
frecuencia de las actualizaciones activadas. Después de enviar una actualización, se
debe configurar un temporizador para un intervalo aleatorio entre 1 y 5 segundos. Si se
producen otros cambios que desencadenarían actualizaciones antes de que expire el
temporizador, se activa una única actualización cuando el temporizador expira. El
temporizador se restablece a otro valor aleatorio entre 1 y 5 segundos.
Las actualizaciones activadas pueden ser suprimidas si se debe realizar una
actualización regular para cuando envíe la actualización activada.

En segundo lugar, las actualizaciones activadas no necesitan incluir toda la tabla de

enrutamiento. En principio, solo aquellas rutas que han cambiado deben ser incluidas.
Por lo tanto, los mensajes generados como parte de una actualización activada deben
incluir al menos aquellas rutas que tengan establecido su indicador de cambio de ruta.
Pueden incluir rutas adicionales, a discreción del implementador, sin embargo, enviar
actualizaciones de enrutamiento completas no es recomendado. Cuando se procesa una
actualización activada, los mensajes deben ser generado para cada red conectada
directamente. El procesamiento de Split Horizon se realiza al generar actualizaciones
activadas, así como actualizaciones normales (ver sección 2.6 ). Si, después del
procesamiento de Split Horizon para una red determinada, una ruta modificada aparecerá
sin cambios en esa red (por ejemplo, aparece con una métrica infinita), la ruta no
necesita ser enviada. Si no es necesario enviar rutas en esa red, la actualización
puede ser omitida. Una vez que todas las actualizaciones activadas han sido generadas,
los indicadores de cambio de ruta deben borrarse.

Si se permite el procesamiento de entrada mientras se genera la salida, se debe hacer

un enclavamiento apropiado. Los indicadores de cambio de ruta no deberían cambiar como
del resultado del procesamiento de entrada mientras se genera un mensaje de
actualización desencadenado.

La única diferencia entre una actualización activada y otros mensajes de actualización

es la posible omisión de rutas que no han cambiado. Los mecanismos restantes, descritos
en la siguiente sección, deben ser aplicado a todas las actualizaciones.

2.5.2 Generando mensajes de respuesta

Esta sección describe cómo se genera un mensaje de respuesta para una red particular
conectada directamente:

La dirección de origen de IPv6 debe ser una dirección de enlace de las posibles
direcciones de la interfaz del enrutador emisor, excepto cuando se responde a un
mensaje de solicitud de unidifusión desde un puerto que no sea el puerto RIPng. En este
último caso, la dirección de origen debe ser una dirección válida globalmente.
En el primer caso, es importante usar una dirección local de enlace porque la dirección
de origen se coloca en tablas de enrutamiento (como el siguiente salto) en los
enrutadores que reciben esta respuesta.
Si se utiliza una dirección de origen incorrecta, es posible que otros enrutadores no
puedan enrutar datagramas.
A veces, los enrutadores se configuran con varias direcciones IPv6 en una sola interfaz
física. Normalmente, esto significa que varias redes lógicas IPv6 se transportan a
través de un medio físico. Eso posible que un enrutador tenga múltiples direcciones
locales de enlace para una sola interfaz. En este caso, el enrutador solo debe originar
un mensaje de respuesta único con una dirección de origen de la dirección local de
enlace designada para una interfaz determinada.
La elección de qué dirección local de enlace usar solo debe cambiar cuando la opción
actual ya no sea válida.
Esto es necesario porque los nodos que reciben los mensajes de respuesta usan la
dirección de origen para identificar al remitente.
Si varios paquetes del mismo enrutador contienen diferentes direcciones de origen, los
nodos supondrán que provienen de diferentes enrutadores, lo que lleva a comportamiento
indeseable.

Establezca el número de versión a la versión actual de RIPng. La versión descrita en

este documento es la versión 1. Establezca el comando en Respuesta. Establezca los
bytes etiquetados "debe ser cero" a cero. Comienzo rellenando RTEs. Recuerde que el
tamaño máximo del datagrama está limitado por la MTU de la red. Cuando no haya más
espacio en el datagrama, envíe la respuesta actual y comenzar una nueva.
Para completar los RTE, examine cada ruta en la tabla de enrutamiento. Rutas para
vincular direcciones locales nunca debe incluirse en un RTE. Si se genera una
actualización activada, solo se deben incluir las entradas cuyos indicadores de cambio
de ruta estén establecidos. Si, después del procesamiento de Split Horizon, la ruta no
debe incluirse, omítala. Si la ruta va a ser incluido, entonces el prefijo de destino,
la longitud del prefijo y la métrica son poner en el RTE. La etiqueta de ruta se
completa como se define en la sección 2.1 . Las rutas deben incluirse en el datagrama
incluso si sus métricas son infinitos.

2.6 Horizonte dividido

Split Horizon es un algoritmo para evitar problemas causados por las rutas incluidas en
las actualizaciones enviadas a la puerta de enlace de la que fueron aprendidas. El
algoritmo básico de Split Horizon omite las rutas aprendidas de un vecino en
actualizaciones enviadas a ese vecino. En el caso de una red de transmisión, todas las
rutas aprendidas de cualquier vecino en esa red se omiten de las actualizaciones
enviadas en esa red.

Split Horizon con Poisoned Reverse (más simplemente, Poison Reverse) incluye tales
rutas en las actualizaciones, pero establece sus métricas en infinito. En efecto,
anunciando el hecho de que no hay rutas accesibles. Este es el método preferido de
operación; sin embargo, las implementaciones deben proporcionar un control por interfaz
que no permita la selección de horizontes, horizontes divididos ni reversiones
envenenadas.

Para una discusión teórica de Split Horizon y Poison Reverse, y por qué son necesarios,
consulte la sección 2.1.1 de [ 1 ].

3 . Funciones de control

Esta sección describe los controles administrativos. Estos no son parte del protocolo
en sí; sin embargo, experiencia con redes existente sugiere que son importantes. Porque
no son necesariamente parte del protocolo, se consideran opcionales. Sin embargo, es
recomendable encarecidamente que al menos algunos de ellos se incluyan en cada
implementación. Estos controles están destinados principalmente a permitir RIPng estar
conectado a redes cuyo enrutamiento puede ser inestable o sujeto a los errores.
Aquí hay unos ejemplos:

- A veces es deseable restringir los enrutadores desde los cuales se aceptarán

actualizaciones o a las cuales se enviarán actualizaciones. Por lo general, se hace por
razones administrativas y de enrutamiento.

- Varios sitios limitan el conjunto de redes que permiten en los mensajes de respuesta.
La organización A puede tener una conexión con la organización B que utilizan para la
comunicación directa. Por seguridad o razones de rendimiento, es posible que A no esté
dispuesto a dar a otras organizaciones acceso a esa conexión. En tal caso, A debería no
incluir las redes de B en las actualizaciones que A envía a terceros.
Aquí hay algunos controles típicos. Tenga en cuenta, sin embargo, que el RIPng el
protocolo no requiere estos u otros controles.

- Una lista de vecinos que permite al administrador de la red poder para definir una
lista de vecinos para cada enrutador. Un enrutador aceptar mensajes de respuesta solo
de enrutadores en su lista de vecinos. Una lista similar para los enrutadores de
destino también debe ser disponible para el administrador. Por defecto, no hay
restricciones definidas.

- Un filtro para destinos específicos permitiría al administrador de la red poder

especificar una lista de prefijos de destino para permitir o no. La lista estaría
asociada a un particular interfaz en las direcciones entrantes y / o salientes. Solo
permitido las redes se mencionarían en los mensajes de respuesta que salen o procesado
en Mensajes de respuesta entrantes. Si aparece una lista de permitidos se especifican
los prefijos, no se permiten todos los demás prefijos. Si una lista de los prefijos no
permitidos se especifica, todos los demás prefijos son permitido. Por defecto, no se
aplican filtros.

4 . Consideraciones de Seguridad

Como RIPng se ejecuta sobre IPv6, RIPng se basa en la autenticación de IP Encabezado

(consulte [ 11 ]) y la carga de seguridad de encapsulación de IP (consulte[ 12 ]) para
garantizar la integridad y autenticación / confidencialidad de intercambios de
enrutamiento.

Referencias
 [ 1 ] Hedrick, C., "Protocolo de información de enrutamiento", RFC 1058 , Rutgers
Universidad, junio de 1988.

[ 2 ] Malkin, G., "RIP Versión 2 - Llevar información adicional",

RFC 1723 , Xylogics, Inc., noviembre de 1994.

[ 3 ] Hinden, R., "Descripción general de la próxima generación de IP" ,

Trabajo en progreso.

[ 4 ] Bellman, R., "Programación dinámica", Universidad de Princeton

Press, Princeton, NJ, 1957.

[ 5 ] Bertsekas, DP, y Gallaher, RG, "Redes de datos", Prentice-

Hall, Englewood Cliffs, Nueva Jersey, 1987.

[ 6 ] Braden, R. y J. Postel, "Requisitos para las puertas de enlace de Internet",

USC / Information Sciences Institute, STD 4, RFC 1009 , junio de 1987.

[ 7 ] Boggs, RD, Shoch, JF, Taft, EA y Metcalfe, RM,

"Pup: An Internetwork Architecture", Transacciones IEEE en Commu-
nicaciones, abril de 1980.

[ 8 ] Ford, LR Jr. y Fulkerson, DR, "Flujos en redes",

Princeton University Press, Princeton, NJ, 1962.

[ 9 ] Xerox Corp., "Protocolos de transporte de Internet", Xerox System Inte-

Gration Standard XSIS 028112, diciembre de 1981.

[ 10 ] Narten, T., Nordmark, E. y W. Simpson, "Neighbour Discovery".

para IP Versión 6 (IPv6) ", RFC 1970 , agosto de 1996.

[ 11 ] Atkinson, R., "Encabezado de autenticación IP", RFC 1826

Laboratorio de Investigación Naval, agosto de 1995.
[ 12 ] Atkinson, R., "IP Encapsulating Security Payload (ESP)",
RFC 1827 , Laboratorio de Investigación Naval, agosto de 1995.
[ 13 ] Floyd, S. y Jacobson, V., "The Synchronization of Periodic
Enrutamiento de mensajes ", Actas de ACM SIGCOMM '93, septiembre 1993.