Usuario:Barcex/Multihoming
Ruego no efectúen cambios aquí hasta que termine y lo pase al artículo real. Es un texto que ya tengo escrito e iré transformando a formato Wiki. Correcciones ortográficas son bienvenidas, tanto como comentarios en la página de discusión. Barcex 01:01 18 sep, 2005 (CEST)
El multihoming de sitio se define como la conexión de un host o sitio a más de un ISP a la vez, y es hoy por hoy un componente esencial para muchos sitios conectados a Internet.
El caso típico de multihoming se ilustra en la Figura 1. El sitio X se conecta a dos ISPs que le dan acceso a Internet. Para ello se utilizan cuatro routers, los que están en el sitio se denominan routers de salida, mientras que los que están en cada uno de los ISPs son los routers de entrada o routers de acceso.
Beneficios[editar]
Hay muchas razones por las que un sitio desearía estar conectado a múltiples ISPs, aunque en la práctica no todas las implementaciones brindan todas las ventajas.
Tolerancia a fallos[editar]
Un sitio con multihoming es inmune a fallas de tránsito o de acceso en alguno de los ISPs que le prestan servicio. Es decir que detectada una falla que afecta a un ISP debiera ser capaz de cursar tráfico a través de otro ISP que no esté afectado por el problema.
Balanceo de carga[editar]
El multihoming permite distribuir el tráfico entrante y saliente entre los distintos ISPs a los que se está conectado. De forma que se tiende a maximizar la utilización de los recursos.
Ingeniería de tráfico[editar]
El sitio puede decidir, en alguna medida, qué tipo y qué volumen de tráfico enviar a cada ISP basándose en aspectos tales como los acuerdos de nivel de servicio, el costo de enviar determinado tipo de tráfico a cada ISP o cualquier otra política que se haya definido.
Independencia de los ISPs[editar]
Normalmente un sitio busca no depender de los ISPs para poder gozar de las ventajas del multihoming. Es por eso que las soluciones de multihoming suelen tener en cuenta que no se necesite de ningún tipo de colaboración especial por parte de los ISPs para implementarlas. Lo que implica que cada sitio puede contratar a distintos ISPs en forma independiente e implementar multihoming por cuenta propia.
Multihoming en IPv4[editar]
A continuación se describirán algunos métodos que se utilizan en IPv4 para realizar multihoming, no siendo estos los únicos disponibles pero sí los más comunes.
Multihoming con direcciones independientes del proveedor[editar]
La forma más común de implementar multihoming en IPv4 es obtener un bloque de direcciones independientes del proveedor (PI) junto con un número de sistema autónomo(ASN) y anunciar el bloque de direcciones vía BGP a cada uno de los ISPs a los que se está conectado.
La Figura 2 muestra un escenario como el descripto, donde un sitio obtiene del registro de Internet correspondiente tanto el ASN 100 como el bloque 100.2.0.0/20 y anuncia este bloque a los dos ISPs a los que está conectado utilizando el protocolo BGP. Luego estos ISPs se encargarán de anunciar a Internet que son capaces de encaminar tráfico destinado hacia tal bloque. De modo que al propagarse esta información por Internet todos los routers que tengan la tabla de encaminamiento global sin ruta por defecto (DFZ) tendrán una entrada correspondiente al bloque 100.2.0.0/20 y podrán encaminar trafico hacia el mismo.
Este esquema presenta problemas de escalabilidad, puesto que por cada sitio con multihoming los routers de la DFZ deben mantener una entrada en su tabla de encaminamiento. Hoy día las tablas de encaminamiento en la DFZ tienen más de 150.000 entradas, lo que dificulta su distribución, procesamiento y sincronización. Adicionalmente hay disponibles solo unos 65.000 números de sistema autónomo, insuficientes para todos los sitios que desearían utilizar multihoming.
Para limitar el crecimiento de las tablas de encaminamiento global los registros regionales de Internet(RIRs) establecen un tamaño mínimo de bloque a asignar. En el caso de RIPE, por ejemplo, la política es que el bloque más pequeño que se asigna es un /21, al cual no pueden acceder la mayoría de los sitios que aspiran a utilizar multihoming.
Por todo esto es que el multihoming con direcciones independientes del proveedor en IPv4 está reservado a sitios medianos a grandes.
Multihoming con direcciones asignadas por el proveedor[editar]
Si a un sitio no le es posible hacer multihoming con direcciones independientes del proveedor aún le es posible obtener un bloque de direcciones de uno de los ISPs que le prestan servicio. Estos bloques de direcciones se conocen como provider aggregatable (PA), y forman parte de la arquitectura CIDR [RFC 1519], la cual asume que las entradas de las tablas de encaminamiento pueden ser agregadas en base a una jerarquía de clientes e ISPs.
Luego el sitio anuncia su bloque PA por BGP a todos los ISPs, los cuales a su vez lo anuncian hacia Internet. Pero el ISP que delegó el bloque, además de anunciar el bloque del sitio anuncia su bloque mayor que lo engloba. De esta forma, aunque el bloque pequeño fuese filtrado en algún lugar de la red, al menos quedaría una ruta hacia el bloque que le dio origen.
La Figura 3 muestra un ejemplo de este caso. El Sitio X está conectado a dos ISPs y obtiene el bloque de direcciones 100.2.3.0/24 de ISP-B a quien su RIR le ha asignado el bloque 100.2.0.0/16. El Sitio X anuncia vía BGP a ambos ISPs su bloque 100.2.3.0/24, utilizando para ello su número de AS 100. Tanto ISP-A como ISP-B vuelven a anunciar el prefijo 10.2.3.0/24 hacia Internet, pero ISP-B también anuncia su prefijo más grande 100.2.0.0/16. En condiciones normales el tráfico fluiría hacia el Sitio X por ambos ISPs. Pero si algún ISP dentro de Internet filtrase el bloque 100.2.3.0/24 por considerarlo muy pequeño solo quedaría en esa parte de la red el prefijo mayor 100.2.0.0/16 y el tráfico fluiría hacia el Sitio X vía ISP-B.
Como se puede observar este modelo de multihoming permite gozar de buena parte de las ventajas del multihoming a sitios que no son lo suficientemente grandes como para obtener un bloque independiente del proveedor.
Una de las desventajas, además del peligro del filtrado, es que si se cambia el ISP que provee las direcciones el sitio tiene que renumerarse, y la renumeración es un proceso costoso en IPv4.
Una variante posible de estos dos últimos modelos es el uso en el sitio con multihoming de números de sistema autónomo privados, lo cual elimina la necesidad de solicitar un número de sistema autónomo a costa de no contar con la independencia que brinda un número de AS propio.
Múltiples conexiones a un mismo ISP[editar]
Si bien este caso no entra en lo que este artículo se define como multihoming, vale la pena comentar su existencia pues es una forma en que los sitios que no pueden acceder a las soluciones anteriores son capaces de obtener algunas de las ventajas del multihoming. Así que no se necesita contar con ningún prefijo en especial ni obtener un número de sistema autónomo, pero se tiene el inconveniente que ante una falla general del ISP se pierde conectividad.
Traducción de direcciones de red (NAT)[editar]
El NAT es por lejos la forma de multihoming más utilizada, donde los sitios realizan una numeración interna con direcciones privadas y traducen las mismas en los routers de salida. De esta forma no hay impacto en la tabla global de encaminamiento. Es el único método de multihoming accesible a sitios pequeños, aunque también lo utilizan muchos sitios medianos y grandes.
El uso de NAT, sin embargo, tiene muchos inconvenientes y por ello es una técnica casi prohibida y muy mal vista en IPv6.
En el ejemplo de la Figura 4 el Sitio X está conectado a 2 ISPs, y recibe un bloque de direcciones de cada uno de ellos.
Del ISP-A recibe el bloque 101.1.1.0/24 y del ISP-B recibe el bloque 102.2.2.0/24. Internamente el sitio utiliza el bloque de direcciones privadas [RFC 1918] 10.20.30.0/24. Cuando los paquetes salen hacia cada uno de los ISPs las direcciones de origen se traducen a direcciones del bloque asignado al sitio por el ISP correspondiente, es decir que el tráfico que sale por ReA utiliza direcciones del bloque 101.1.1.0/24 y el tráfico que sale por ReB utiliza direcciones del bloque 101.2.2.0/24.
Multihoming en IPv6[editar]
Arquitectura de direccionamiento de IPv6[editar]
El formato general de una dirección unicast [IPv6] es el siguiente:
Los primeros 48 bits forman la parte pública de la dirección y están asignados en forma jerárquica por los RIRs y los ISPs.
El ID de subred es un identificador de cada subred dentro del sitio. Se deja libre a cada sitio para implementar el esquema de asignación de este identificador. Aunque se espera que se haga en forma jerárquica también dentro del sitio.
El identificador de interfaz es un número único que identifica a una interfaz dentro de una subred (link). En redes Ethernet el identificador de interfaz se calcula a partir de la dirección MAC del adaptador.
En la Figura 5 se presenta un ejemplo de esta asignación jerárquica de tipo provider aggregatable (PA) que se utiliza en IPv6. El ISP-A recibe de su RIR el prefijo 2001:100::/35 mientras que el ISP-B hace lo propio con el prefijo 2001:200::/35. A su vez cada uno de los ISPs asigna un prefijo de longitud 48 al Sitio X, prefijo que forma parte de su propio espacio de direccionamiento. Es así que el Sitio X obtiene los prefijos 2001:100:10::/48 y 2001:200:20::/48. Luego al Host X se le asignan dos direcciones globales IPv6: 2001:100:10:15::25 y 2001:200:20:15::25. De esta forma no se rompe la jerarquía de direccionamiento y el Host X puede utilizar ambos ISPs.
Características deseadas del multihoming en IPv6[editar]
El esquema jerárquico presentado no es suficiente para brindar en IPv6 las mismas características que se pueden lograr en IPv4 utilizando direccionamiento independiente del proveedor. Por ejemplo, si fallase el acceso a uno de los ISPs, todas las conexiones con direcciones pertenecientes a su bloque perecerían.
RFC 3582 establece cuales debieran ser las características que que se desearía posean los distintos métodos de multihoming propuestos para IPv6:
- Redundancia: El sitio debiera ser inmune a fallas que ocurran en uno de los ISPs.
- Balanceo de carga: El sitio debiera poder distribuir la carga de tráfico entrante y saliente entre los distintos ISPs.
- Rendimiento: El sitio debiera poder reaccionar ante problemas de rendimiento y/o congestión en alguno de los ISPs.
- Ingeniería de Tráfico: El sitio debiera poder decidir enviar distinto tipo y/o volumen de tráfico por cada uno de los ISPs en función de políticas definidas.
- Simplicidad: Las soluciones debieran ser lo suficientemente simples como para poder implementarse en sitios reales de distinto porte.
- Supervivencia de las conexiones de transporte: En caso de fallo en uno de los ISPs, y el consecuente cambio de las direcciones IP para llegar al mismo destino, las conexiones de transporte debieran poder permanecer activas.
- Impacto en el DNS: Se esperaría que el multihoming sea compatible con el DNS actual, y si es necesario realizar cambios que estos puedan ser desplegados sin inconvenientes.
- Filtrado de ingreso: El multihoming debe ser compatible con los filtros de ingreso que implementan normalmente los ISPs.
Supervivencia de las conexiones de transporte[editar]
Tradicionalmente en IP se ha asumido que los hosts no se movían. Es por ello que la dirección IP ha tenido los siguientes significados:
- Identidad (Quien): se asocia la dirección IP con un host en particular.
- Localización (Donde): la dirección IP indica el lugar de la red donde se encuentra un host.
- Encaminamiento (Cómo): la dirección IP determina el camino a seguir para alcanzar al host.
Estos tres significados se disocian en el caso del multihoming, dado que para una misma identidad la localización puede cambiar, y al cambiar ésta también cambia el encaminamiento.
Entonces es necesario separar la identidad de la localización. Para ello se ha propuesto un nuevo esquema de separación conocido como Identidad/Localizador (ID/Locator).
La idea detrás de este concepto de Identidad/Localizador es que la Identidad permanece inalterable durante todo el tiempo que dura la comunicación, pero los localizadores pueden cambiar. Varios de los mecanismos que se comentarán más adelante en esta sección utilizan de alguna forma el concepto de Identidad/Localizador con el objeto de que las conexiones de transporte sobrevivan a los cambios de direcciones (localizadores) originados por fallas.
Clasificación de las soluciones[editar]
Habiendo muchos mecanismos de multihoming se hace necesario categorizarlos de alguna forma para poder compararlos. Es así que en [AAMH] se presenta una forma de clasificarlos. Antes de proceder al tratamiento de los mecanismos más relevantes se presentan las categorías y se indica a cual de ellas pertenece cada una de las soluciones que se tratarán luego.
- Encaminamiento: Utilizar el mismo esquema que se utiliza en IPv4.
- Movilidad: Utilizar el protocolo MIPv6.
- Crear un nuevo elemento de protocolo: Insertar un nuevo elemento en la pila de protocolos que maneje identidades persistentes para las sesiones. Usada en HIP y Multi6 L3 Shim.
- Modificar un protocolo existente: Modificar el protocolo de transporte o el protocolo IP para permitir cambios de localizadores dinámicamente. Usada en la propuesta de modificar TCP.
- Modificar la interacción entre los routers de salida y los hosts locales: Implementar técnicas como encaminamiento basado en origen, reescritura de direcciones de origen, etc. Utilizada en la aproximación Host Centric.
Solución de encaminamiento similar a IPv4[editar]
Se puede utilizar la misma solución de encaminamiento que en IPv4, pero tampoco es escalable por lo que queda descartada por la misma arquitectura de direccionamiento que obliga a mantener la jerarquía.
MIPv6[editar]
Una de las propuestas que se ha analizado para solucionar el problema del multihoming ha sido el uso del protocolo Mobile IPv6 [RFC 3775]. La idea ha sido buscar un paralelismo entre el problema de la movilidad y el problema del multihoming. Bajo este punto de vista se considera que un host con multihoming es equivalente a un host móvil que se “mueve” cada vez que hay una falla y debe cambiar sus localizadores para utilizar un ISP alternativo. De esta forma se intenta que las conexiones se preserven.
Si bien pareciera que es posible implementar esta analogía, la forma en que MIPv6 lleva a cabo su tarea no es capaz de solucionar completamente el problema del multihoming.
Para abordar estos inconvenientes aquí habría que detallar el funcionamiento del complejo protocolo MIPv6. Es por eso que se dará una explicación simplificada de los problemas que trae aparejados el uso de MIPv6 para obtener multihoming.
En MIPv6 cuando un nodo móvil desea informar al otro extremo que se ha movido y que por lo tanto tiene una nueva dirección IP se utiliza un mensaje denominado Binding Update (BU). Luego, los procedimientos de seguridad de MIPv6 imponen la realización de un procedimiento denominado return routability (RRP) antes de comenzar a utilizar la nueva dirección. Desafortunadamente uno de los pasos de este procedimiento implica enviar y recibir un mensaje utilizando la dirección original que el host tenía (home address).
En el caso del multihoming el envío de este mensaje no sería posible pues justamente es porque la dirección original no funciona que se quiere cambiar de dirección. A pesar de ello es posible realizar este procedimiento por adelantado para poder cambiar de dirección si ocurriese una falla, pero el procedimiento tiene un tiempo de vida limitado y debe realizarse periódicamente. Para estar protegido todo el tiempo, entonces, el nodo con multihoming debiera realizar el RRP al menos cada 135 segundos.
Aunque ejecutar este procedimiento frecuentemente no supondría una carga excesiva, el mayor problema es que el uso de una nueva dirección con la claves creadas durante la última vez que se ejecutó el RRP está limitado a 420 segundos. Y como una vez ocurrida la falla no es posible repetir el RRP la solución estaría limitada a fallas que duren como máximo 7 minutos, tiempo muy pequeño comparado con la duración típica de las fallas.
Otra limitación derivada de estos procedimientos es que una vez que ocurre una falla y se pasa a utilizar una segunda dirección no se puede pasar a una tercera si la segunda también falla. Aunque esto solo afectaría a sitios medianos o grandes que pueden estar conectados a más de dos ISPs, y no a los sitios pequeños que normalmente estarán conectados a dos ISPs solamente.
Así y todo sería posible realizar algunas modificaciones a MIPv6 para paliar estos inconvenientes, aunque no está a la vista que en los grupos de trabajo de IETF se esté considerando.
Host Identity Protocol (HIP)[editar]
HIP es un mecanismo que separa la capa de transporte de la capa de red introduciendo entre ellas una nueva capa de forma que los sockets no están ligados a direcciones IP. HIP introduce un nuevo espacio de nombres para los hosts entre las capas de transporte y de red. En HIP los sockets de capa de transporte están ligados a identificadores, y estos identificadores están ligados dinámicamente a direcciones IP (localizadores).
El espacio de nombres HIP está formado por identificadores de host (HI). Cada HI es la clave pública de un par de claves criptográficas asimétricas y se asigna un HI a cada host. Cada host tendrá al menos una identidad de host y su correspondiente identificador de host.
La diferencia entre identidad de host e identificador de host radica en que la primera se refiere a la entidad abstracta que se está identificando, mientras que la segunda se refiere a un patrón de bits en particular que se está utilizando en el proceso de identificación.
Para lograr su cometido la especificación crea un nuevo protocolo denominado Host Identity Protocol (HIP) y un procedimiento de intercambio criptográfico llamado HIP base exchange.
Cuando un host desea cambiar su dirección IP, como es en el caso del multihoming, envía un mensaje HIP Readdress a su par. Luego de un procedimiento de verificación de alcanzabilidad que realiza el otro extremo utilizando los mensajes HIP Address Check y HIP Address Check Reply la nueva dirección se puede comenzar a utilizar.
HIP también sirve como un mecanismo de transición entre IPv4 e IPv6 puesto que al presentar a las capas superiores identificadores y no direcciones éstas no son conscientes del protocolo que se está utilizando en la capa IP. (Esto no es correcto, ya que esto no resuelve la conectividad a nivel de red, ya que a pesar de este protocolo, una máquina con IPv4 podría no poder comunicarse con una máquina IPv6, a pesar de que la conectividad a niveles superiores sí que quedaría garantizada).
Si bien HIP permite preservar las comunicaciones ante fallas en el caso de multihoming, no tiene características de ingeniería de tráfico ni de selección de direcciones.
Layer 3 Multi6 Shim[editar]
El seno del grupo de trabajo multi6 del IETF se ideó un nuevo protocolo que tiene como objetivo preservar comunicaciones establecidas en entornos con multihoming. Como consecuencia de ello se formó un nuevo grupo de trabajo denominado shim6 que está encargado de diseñarlo.
La aproximación, conocida como Layer 3 Shim inserta una subcapa entre las subcapas de extremo y de encaminamiento de IP (ver Figura 7).
La idea es asegurar que todos los protocolos de capa superior sean capaces de operar sin modificación alguna en un entorno con multihoming, es decir que vean siempre direcciones IPv6 estables pase lo que pase en las capas inferiores. Es por ello que no se introduce un nuevo espacio de nombres como identificadores sino que se usa uno de los localizadores (direcciones) como identificador. Estos identificadores se denominan upper layer identifiers (ULIDs) y son escogidos de acuerdo con lo establecido en [RFC 3484].
Por debajo de la subcapa de extremo de IP se seleccionan de forma transparente los localizadores que se van a utilizar en la comunicación. Cuando falla la comunicación la subcapa Multi6 shim es capaz de probar y seleccionar nuevos localizadores.
El ubicar la capa Multi6 shim por debajo de AH y ESP tiene como objetivo que IPSec no note los cambios en los localizadores y las asociaciones de seguridad permanezcan estables. Ubicar la nueva capa por debajo de la fragmentación y el reensamblado hace a este último más confiable pues pudiese suceder que distintos fragmentos de un mismo paquete utilizasen distintos localizadores.
La capa Multi6 mantiene estado y debe ser capaz de mapear los ULIDs en localizadores y viceversa, tanto en el emisor como en el receptor. El estado se mantiene por cada ULID remoto y se denomina host-pair context.
La Figura 8 ejemplifica cómo se mapean los ULIDs y los localizadores. Tanto el Host A como el Host B cuentan con tres localizadores (direcciones) cada uno: L1(A), L2(A), L3(A) el Host A y L1(B), L2(B) y L3(B) el Host B. En este caso las capas superiores (ULP) tanto del Host A como del Host B ven los identificadores L1(A) y L1(B), aunque en realidad los paquetes IP circulan por la red con direcciones (localizadores) L2(A) y L3(B). Es la capa Multi6 la que realiza este mapeo.
Para establecer el contexto cuando un extremo A quiere iniciar comunicación con un extremo remoto B sigue los siguientes pasos:
- A consulta al DNS por los registros AAAA correspondientes al nombre de B. Estos registros son los localizadores de B. Entonces A toma el primero de los localizadores y establece que el ULID de B será el primer localizador de la lista: ULID(B) = L1(B).
- La capa ULP crea el estado que sea pertinente a la misma utilizando el par de ULIDs: ULID(A) = L1(A) y ULID(B) = L1(B). Es decir que inicialmente el ULID local es una de las direcciones locales escogida con los mecanismos normales de selección de direcciones de origen y el ULID remoto es una de las direcciones remotas. Entonces la capa ULP envía el primer paquete de la comunicación hacia la capa Multi6 de A.
- El paquete pasa por la capa Multi6, la cual hasta ese momento no cuenta con estado para ULID(B). La política local de A determinará cuando se va a intentar establecer estado a nivel Multi6 con B. Mientras tanto todo el tráfico pasa entre A y B en IPv6 normal, usando a L1(A) y L1(B) como direcciones (localizadores) IPv6 de los paquetes.
En el momento en que la política vigente en A o B lo determine se lleva a cabo el establecimiento de estado Multi6. Si el establecimiento tiene éxito, entonces cada extremo recibe el conjunto de localizadores del otro. En este momento ya es posible cambiar los localizadores que se usan en los paquetes si algún evento lo impone. Si no se establece estado los paquetes siguen fluyendo con IPv6 normalmente.
Cuando un host detecta que la comunicación no está funcionando puede intentar cambiar a otro par de localizadores. Pero antes de hacerlo debe probarlos, tanto para para verificar que el par de localizadores está activo como para prevenir ataques de denegación de servicio.
El proceso de traducción de localizadores a identificadores cuando se recibe un paquete se denomina demultiplexación. Por ejemplo, El Host B en la Figura 8 demultiplexa el paquete recibido con localizadores L2(A) y L3(B) traduciéndo los mismos a los identificadores L1(A) y L1(B) respectivamente para ser presentados al protocolo de capa superior. Aún no está totalmente definida la forma de realizar la demultiplexación, existiendo varias alternativas para resolver las ambigüedades que pudiesen presentarse.
La forma exacta de mantener el estado y de manejar los conjuntos de localizadores dinámicamente está en discusión actualmente en el grupo Multi6. Sin embargo está claro que Multi6 Shim está evolucionando hacia la propuesta que se va a estandarizar en IETF.
SCTP[editar]
Una solución de multihoming a nivel de transporte es Stream Control Transmission Protocol (SCTP). Especificado en [RFC 2960], SCTP es un protocolo de transporte alternativo a TCP y UDP. Aunque fue desarrollado inicialmente para brindar un mecanismo de transporte orientado al mensaje que sirviese para enviar señalización telefónica, es un protocolo de propósito general con muchas características y puede reemplazar tanto a TCP como a UDP, agregando además otras ventajas.
Entre las ventajas de SCTP está el soporte de multihoming y la posibilidad de multiplexar distintos flujos de datos (streams) en una misma asociación.
En la Figura 9 se ilustra un ejemplo de cómo funciona el soporte de multihoming en SCTP. Hay dos Hosts, X e Y. El Host X está conectado a dos ISPs y por lo tanto tiene las direcciones A:X1 y B:X2. Por otro lado, el host remoto Y también tiene un par de direcciones, C:Y1 y D:Y2. En el ejemplo hay asociación establecida entre los puertos 1234 de Host X y 1111 de Host Y.
En SCTP aparece claramente la separación Identidad/Localizador a nivel de transporte. Al establecerse la asociación cada extremo notifica al otro cuales son todas sus direcciones (localizadores), estableciéndose así múltiples caminos de transmisión, como los representados en la Figura 9, y se elige un camino de transmisión primario a través del cual se llevará a cabo el intercambio de datos.
A pesar de ello cada extremo de la asociación monitoriza constantemente el estado de los demás caminos que no están siendo utilizados para enviar datos. Cada uno de estos caminos puede estar entonces en estado activo o inactivo. Si está en estado activo quiere decir que las pruebas que se han realizado recientemente indican que se puede enviar tráfico por el, si estas pruebas fallan, entonces el camino se marca como inactivo.
Si el camino de transmisión primario fallase, y por lo tanto se volviese inactivo, el extremo escogerá otro camino que esté en estado activo y cursará el tráfico por el mismo.
Además hay una extensión que permite agregar y eliminar direcciones IP en forma dinámica al conjunto de direcciones (localizadores) que utiliza una asociación, permitiendo así que ante procesos de renumeración las asociaciones se mantengan vivas.
Preservación de las conexiones TCP activas[editar]
Hay una propuesta para preservar las conexiones TCP activas. El método consiste en incluir una un par de opciones IPv6 llamadas PREFIXES y PREFIXES_ACK en los paquetes que llevan segmentos TCP SYN y SYN/ACK.
De esta forma en el momento de establecer la conexión TCP los extremos darían a conocer cuales son todas sus direcciones IP. Si hubiese un problema y fuese necesario cambiar de dirección IP en algún momento cualquier host podría utilizar una de esas direcciones anunciadas al inicio de la conexión, pero no se contempla el caso de que a un extremo se le agregue una nueva dirección.
Host Centric[editar]
Como ya se ha mencionado, IPv6 se ha diseñado con una arquitectura de direccionamiento jerárquica conocida como Provider Aggregatable (PA). Como consecuencia de ello cada ISP asigna un prefijo a cada sitio al que presta servicios, prefijo este que es un subconjunto de un prefijo más grande que el ISP tiene asignado para si. Esto le permite al ISP anunciar solamente en las tablas globales de encaminamiento su prefijo más grande, que engloba a todos los sub-prefijos que asigna a sus clientes.
Por razones de escalabilidad no es una práctica permitida el que un ISP anuncie parte de un prefijo que le ha sido asignado a otro ISP. De modo que la vía de entrada a un sitio conectado a varios ISPs queda determinada por el prefijo al que pertenece la dirección de destino de cada uno de los paquetes que desean entrar.
Para lograr los objetivos del multihoming es necesario poder cursar tráfico por varios ISPs a la vez. Lo que obliga a que cada host en un sitio tenga al menos una dirección IP por cada prefijo asignado al sitio. Así, en un escenario típico, si un sitio está conectado a n ISPs cada host que quiera hacer uso del multihoming tendrá n direcciones IP asignadas, una por cada ISP.
La solución genérica de multihoming conocida como Host Centric fuerza a los hosts a elegir las direcciones de origen y destino de cada paquete de forma que se haga el mejor uso posible de los recursos de red disponibles.
Elección de la dirección de destino[editar]
Antes de establecer una comunicación lo primero que debiera hacer un host que implementa Host Centric es determinar la dirección IP de destino a utilizar. Comúnmente estas direcciones se obtienen del DNS, pero aunque el DNS puede entregar múltiples direcciones para un mismo destino, no es capaz de indicar fehacientemente cual es la mejor dirección a utilizar. La RFC 3484 establece criterios para la elección de la dirección de destino entre las obtenidas del DNS, criterios que, aunque no tienen en cuenta completamente el estado de la red, al menos evitan que la selección sea totalmente arbitraria. En sitios grandes y complejos se podría implementar un sistema que basado en información de encaminamiento y de políticas decidiese qué dirección de destino, entre las alternativas, es la más adecuada. Pero en todo caso al menos está la posibilidad de probar una por una hasta poder establecer la comunicación, como se sugiere en RFC 3484.
Elección de la dirección de origen[editar]
Luego de elegida la dirección de destino debiera procederse a la elección de la dirección de origen. Esta selección será determinante en la elección del camino del tráfico entrante ya que para un paquete con origen remoto la arquitectura jerárquica de direccionamiento impone cual es la entrada basándose en la dirección de destino de cada paquete de respuesta. Es más, cómo se verá posteriormente, los ISPs aplican filtros de ingreso que solo permiten cursar tráfico saliente del sitio que lleve sus propias direcciones de origen, por lo que de hecho la elección de la dirección de origen también lleva consigo la elección del proveedor de salida.
Al tener cada host al menos una dirección por cada ISP al que se encuentra conectado el sitio, es el mismo host el que se ve obligado a hacer la elección de la dirección de origen. Nuevamente la forma de realizar esta elección tiene varias alternativas. Desde la elección con muy poca información por parte de los sitios pequeños, especificada en RFC 3484, pasando por la distribución de políticas de selección hasta llegar a esquemas de consultas a un servidor que tomará la decisión basado en información proveniente de los protocolos de encaminamiento exterior.
El problema del filtrado de ingreso[editar]
Los ISP normalmente aplican filtros al tráfico que reciben desde los clientes. Este filtrado, que tiene como objetivo evitar ataques de tipo spoofing de dirección IP de origen, consiste en permitir ingresar sólo tráfico cuya dirección de origen pertenezca a los prefijos que el ISP ha asignado al cliente.
Puesto que en un sitio con multihoming habría al menos un prefijo por cada ISP al que el sitio esté conectado. Si un paquete saliese por un ISP distinto al de su dirección de origen este sería filtrado.
Por ejemplo, en la Figura 10 el Sitio X está conectado a dos ISPs, ISP-A e ISP-B. Por consiguiente tiene asignados dos prefijos: A y B. El Host X tiene pues dos direcciones IP, A:X1 y B:X2. Si para comunicarse con el Host Y eligiese la dirección de origen A:X1, y el IGP del Sitio X, por la razón que sea, eligiese a ReB como router de salida este paquete sería filtrado por RiB a la entrada de ISP-B. Por el contrario, si el IGP eligiese a ReA como router de salida el paquete no sería filtrado por RiA y llegaría a destino.
Por tanto es muy importante contar con un método para sortear este problema, pues de otro modo buena parte del tráfico perecería en manos de los filtros de ingreso.
Relajar los filtros de ingreso[editar]
Si no fuese posible quitar los filtros de ingreso el problema podría solucionarse relajándolos, permitiendo inyectar en cualquier ISP tráfico proveniente de cualquiera de los prefijos asignados al sitio.
Lamentablemente esta solución está solo reservada a sitios medianos o grandes en los que el sitio cuente con la suficiente confianza por parte de sus ISPs o con suficiente poder de negociación.
En la Figura 11 se representan los filtros relajados, donde los routers de entrada aceptan tanto tráfico proveniente de direcciones de origen asignadas por el ISP-A o del ISP-B.
Este tipo de encaminamiento puede generar tráfico asimétrico, el cual puede no ser del todo deseable en alguna situación en particular.
IGP con encaminamiento basado en origen[editar]
Si el IGP del sitio con multihoming permitiese encaminamiento basado en origen (SAD), este sería capaz de encausar los paquetes hacia el router de salida correspondiente a la dirección de origen elegida.
El encaminamiento SAD [SADR] se basa en que los routers mantienen distintas tablas de encaminamiento para los distintos prefijos de direcciones de origen existentes en el sitio. Luego los paquetes son encaminados utilizando la tabla correspondiente a su dirección de origen.
Podría verse el sistema completo de encaminamiento como una serie de planos en paralelo donde los caminos para llegar a un mismo destino son diferentes e independientes para cada prefijo de direcciones de origen.
En esta aproximación la elección del ISP de salida, y del correspondiente router, la realiza indirectamente el host en el momento de elegir la dirección de origen. De modo que desde el punto de vista de ingeniería de tráfico es el host el que toma las decisiones, y no el sistema de encaminamiento.
Encaminamiento mixto[editar]
Si no es posible que todo el sistema autónomo utilice un IGP con encaminamiento basado en origen, al menos es posible realizar una transición teniendo un sistema de encaminamiento mixto. En este esquema una zona del IGP encamina en forma genérica (solo por dirección de destino) y otra zona, en la que se encuentran todos los routers de salida, encamina por dirección de origen (zona SAD). De esta forma un paquete que se genera en la zona de encaminamiento genérico atraviesa la misma hasta entrar en algún punto a la zona SAD. Una vez allí el propio IGP llevará al paquete hacia el router de salida correcto.
Puesto que no hay una relación estrecha entre el punto de ingreso a la zona SAD y el router de salida al que se dirigirá el tráfico, deberá haber al menos un camino entre cualquier punto de ingreso a la zona SAD y cada uno de los routers de salida. Por el contrario, no se requiere que toda la zona de encaminamiento genérico esté conectada entre si, siempre que se pueda llegar a algún router de entrada a la zona SAD.
El ejemplo de la Figura 13 ilustra un escenario con encaminamiento mixto. El Sitio X se compone de dos zonas:
- Zona con encamiento SAD: formada por los routers R1, R2, R3, ReA y ReB. Se observa que se trata de una zona contígua y que desde R1, R2 y R3 se puede llegar tanto a ReA como a ReB.
- Zona sin encaminamiento SAD: formada por los routers Ra, Rb, Rc y Rd. Se observa que hay dos sub-zonas discontiguas, una formada por Rb, Rc y Rd; y otra formada por Ra solamente.
Esta solución tiene el inconveniente de que la ruta seguida puede no ser óptima, pues el encaminamiento dentro del sistema autónomo tiene dos trayectos consecutivos, uno dentro de cada zona, y la combinación de ambos puede no resultar en el trayecto óptimo.
Por ejemplo en la Figura 13 si el Host Z elige comunicarse con el Host Y utilizando la dirección de origen A:Z1 y la parte del IGP sin encaminamiento SAD dirige el paquete hacia R1 éste deberá ser reencaminado hacia ReA por el IGP con encaminamiento SAD. Camino que insume al menos un salto más que si el paquete entrase a la Zona SAD vía R2.
De todos modos, como solución de transición es aceptable, pues permite a ambos sistemas de encaminamiento convivir mientras paulatinamente la zona de encaminamiento basado en origen va creciendo hasta convertirse en la única zona.
Zona desmilitarizada (DMZ)[editar]
Otra solución posible sería conectar a todos los routers de salida a un mismo enlace. Todos estos routers debieran ser capaces de encaminar basándose en la dirección de origen. De modo que si un paquete llegase a un router de salida que no es el correcto éste lo reenviaría hacia el router correcto (que es su vecino), añadiendo así un salto más.
Este esquema soluciona el problema del filtrado de ingreso, pero no permite tener routers de salida geográficamente dispersos ya que todos deben estar interconectados por un mismo enlace.
Cada uno de estos routers de salida debiera ser capaz de asociar a cada posible prefijo del sitio una dirección de router de salida.
Por ejemplo en la Figura 14 los routers de salida ReA y ReB comparten un enlace (DMZ). Cada router puede encaminar basándose en direcciones de origen y conoce cual es el router de salida para cada prefijo del sitio. En este caso ReA conoce que los paquetes que arriben con dirección de origen A:* deben ser enviados a RiA y los que arriben con dirección de origen B:* deben ser enviados a ReB. Lo mismo sucede para ReB, que sabe que los paquetes con origen A:* deben ser enviados a ReA y los paquetes con origen B:* deben ser enviados hacia RiB.
Malla de túneles[editar]
Si no fuese posible conectar todos los routers de salida a un mismo enlace se podría utilizar una malla de túneles entre los routers de salida. De modo que al recibir un un paquete que debió salir por otro router se procede a enviarlo mediante un túnel hacia el router de salida correcto.
Este esquema puede ser poco óptimo, pues mientras el sistema de DMZ solo agrega un salto, el de malla de túneles puede resultar en una cantidad de saltos muy superior a la óptima, además de la carga extra de encapsular y desencapsular un paquete en un túnel.
Por ejemplo en la Figura 15 si el Host X enviase un paquete hacia el Host Y y el paquete tomase el camino Ra-Rb-ReA este debe ser encapsulado por ReA en un túnel con origen ReA y destino ReC. Este túnel agrega al menos 3 saltos (ReA-Rc-Re-ReC) al camino completo.
Túneles automáticos[editar]
Un inconveniente que comparten estos dos últimos métodos es que en ambos los routers deben conocer la lista de prefijos del sitio y los routers de salida para cada prefijo.
Esta información puede configurarse manualmente, pero la administración de esta configuración no es escalable ya que se debe mantener en el sistema un túnel y/o ruta para cada prefijo con que cuente el sitio. Estos túneles podrían ser configurados mediante un servidor de políticas o bien en forma automática.
Teniendo en cuenta la arquitectura de direccionamiento de IPv6 se podría suponer que todos los prefijos de un sitio tendrán la misma longitud L (típicamente 48).
Luego, a partir de una dirección de origen, podría derivarse el prefijo de sitio al que corresponde ésta simplemente poniendo en 0 en la misma los 128-L últimos bits.
Contando ya con un prefijo de sitio sería posible construir una dirección de host (tipo anycast), llamada site-exit anycast que representase al router de salida correspondiente al prefijo en cuestión.
La propuesta es que esta dirección no coincida con la de otro host o router dentro del sitio, por lo que se ha pensado en formarla tomando el prefijo y poniendo en 1 los últimos 128-L bits. De modo que por ejemplo para L=48 y la dirección IP 2001:1111:2222::3333 correspondiente al prefijo de sitio 2001:1111:2222::/48 la site-exit anycast correspondiente sería 2001:1111:2222:ffff:ffff:ffff:ffff:ffff.
Cada router, para cada uno de los prefijos para los que actúa como router de salida, asignaría a sus interfaces internas al sitio las direcciones site-exit correspondientes. Entonces inyectaría en el IGP correspondiente estas direcciones.
En otro extremo del sistema autónomo un router de salida al recibir vía el IGP un prefijo correspondiente a una dirección site-exit conocería la existencia del prefijo en el sitio. Con esta información ya podría enviar todos los paquetes con dirección de origen perteneciente a ese prefijo al router de salida correcto a través de un túnel cuyo destino es la dirección site-exit recibida.
En la Figura 17 se ve que los routers ReA, ReB y ReC se asignan las direcciones site-exit A:1...1, B:1...1 y C:1...1 respectivamente, y las inyectan dentro del IGP. Luego, a través del IGP los mismos routers pueden identificar que los prefijos del sitio son A:*, B:* y C:*. Cuando, por ejemplo, arribe un paquete con dirección de origen C:X3 a ReA este lo encapsulará dentro de un nuevo paquete IP con origen ReA y destino C:1...1, realizando de esta forma un túnel automático
La única configuración que debe realizarse en cada router es activar el soporte de túneles automáticos de multihoming, asignar la dirección site-exit correspondiente a los prefijos de los ISPs a los que él se conecta y redistribuir estas direcciones en el IGP.
Túneles automáticos desde routers internos[editar]
Una optimización del sistema de túneles automáticos propuesto podría consistir en permitir a determinados routers internos realizar túneles automáticos hacia los routers de salida correspondientes. De esta forma, si un paquete que debe salir del sitio pasa por uno de estos routers internos el mismo puede encapsularlo en un túnel y enviarlo directamente hacia el router de salida pertinente, sin correr el riesgo de que el paquete llegue a un router de salida incorrecto. Mejorándose así la optimización de los caminos.
La forma de realizar esta tarea es la misma que la descripta anteriormente pues estos routers también tienen acceso a reconocer las direcciones site-exit anycast disponibles por ser éstas distribuidas a través del IGP.
Esta solución sería transitoria hasta contar en todo el sitio con un IGP capaz de implementar encaminamiento SAD.
En la Figura 18 se ejemplifica un caso donde el router Rf es capaz de reconocer los prefijos del sitio y encaminar el tráfico con destino externo al sitio directamente hacia el router de salida. Esto lo hace encapsulando cada paquete en un túnel cuyo destino es el router de salida correspondiente.
Sin esta optimización, por ejemplo, un paquete con origen generado por el Host Z con dirección de origen A:Z1 y destino D:Y podría llegar a Rb y de ahí tener que ser reencaminado vía un túnel hacia ReA, hecho que agregaría tres nuevos saltos. Con la optimización, al poder Rf reconocer cuales son los routers de salida, diréctamente podría ser encapsulado en un túnel desde Rf hasta ReA. Con la ventaja de que este túnel toma el camino óptimo entre Rf y ReA, puesto que el túnel es un paquete con origen Rf y destino ReA que será encaminado por el camino que el IGP considere óptimo entre Rf y ReA. Una vez llegado a ReA el paquete será retirado del túnel y enviado a RiA donde seguirá su camino hasta D:Y.
Detección de router de salida[editar]
En varias de las soluciones planteadas puede producirse un encaminamiento no óptimo entre el host y el router de salida. Una forma de optimizar este camino es implementando un mecanismo de detección del router de salida, donde el host deberá colaborar.
En este esquema, cuando un router de salida recibe un paquete con una dirección de origen correspondiente a otro router de salida lo envía hacia el router correspondiente, ya sea directamente o mediante un túnel. A pesar de esto, también envía un mensaje ICMP de error de tipo Destination Unreachable con código 5 cuya semántica indica que la dirección de origen ha sido rechazada por los filtros de ingreso.
Si el que lo recibe es un host heredado no le prestará atención a este mensaje y los paquetes continuarán siendo encaminados en forma no óptima.
Pero si el host que recibe el mensaje ICMP puede comprenderlo sabrá interpretar que se trata de una indicación de que el camino que se está usando no es óptimo. Acto seguido el host calculará la dirección site-exit correspondiente a la dirección de origen en cuestión y enviará los paquetes con esa dirección de origen directamente hacia el router de salida correcto mediante un túnel. La dirección del router de salida correcto es la site-exit calculada.
Ingeniería de tráfico[editar]
En un sistema en donde las decisiones acerca de los caminos de entrada y salida de tráfico son tomadas individualmente por los hosts y no por el sistema de encaminamiento del sitio se presenta el desafío de diseñar una solución que permita implementar algún grado de ingeniería de tráfico (TE).
Un punto a destacar es que con esta arquitectura el extremo que inicia la comunicación es quien elige el camino de entrada, y generalmente también el de salida. Es así que el problema debe abordarse desde dos puntos vista: el de las comunicaciones salientes y el de las entrantes.
Comunicaciones salientes[editar]
Aunque útil, el algoritmo básico de selección de direcciones especificado en RFC 3484 no es capaz de realizar siempre buenas elecciones. Especialmente cuando un host cuenta con múltiples direcciones globales y desea conectarse con un host externo, éste no cuenta con información acerca de qué ISP es el mejor para llegar a destino.
En este caso el algoritmo de selección de direcciones estándar termina seleccionando la dirección de origen más “parecida” a la de destino, es decir con la que comparta la mayor cantidad de bits iniciales. Se necesita un método que haga una elección un poco más inteligente.
Aún cuando RFC 3484 especifica el uso de una tabla de políticas que permite seleccionar distintas direcciones de origen para distintos destinos, no especifica una forma de actualizarla dinámicamente.
Al igual que en casi todos los aspectos del multihoming se presentan distintas soluciones que podrían aplicarse ante distintos escenarios. En este caso las principales son:
- Sistema de distribución de políticas de selección de direcciones de origen.
- Sistema de consulta con servidor centralizado para la elección de las direcciones de origen. Por ejemplo: NAROS.
Distribución de políticas de selección de direcciones de origen[editar]
Se ha propuesto un método para que los ISPs puedan distribuir a sus clientes políticas de selección de direcciones, y que éstas lleguen a cada uno de los nodos de la red del cliente.
La idea es que los ISPs utilicen las opciones de prefijo RFC 3633 para delegar prefijos a sus clientes. Se propone una nueva opción de DHCPv6 que distribuya una política de selección de direcciones en combinación con cada prefijo delegado.
Luego dentro del sitio se propone combinar las políticas recibidas de cada ISP y distribuirlas a los hosts ya sea a través de una extensión del mensaje Router Advertisement [SPND] o una nueva opción de DHCPv6.
Un punto interesante de esta propuesta es que el pasaje, procesamiento, generación y distribución de las políticas puede hacerse en forma automática para el cliente. Lo que la hace particularmente interesante para sitios pequeños.
Los sitios con topologías un poco más complejas podrían ser configurados para manipular o agregar información a las políticas recibidas por parte de los ISPs y así influir en el proceso de selección.
La Figura 21 muestra un ejemplo de este tipo de distribución de políticas. El Sitio X está conectado a ISP-A e ISP-B, los cuales le asignan a través de la opción DHCP de distribución de políticas (DHCP-PD) los prefijos 2001:1111:a::/48 y 2002:2222:b::/48. Además de la asignación de prefijos cada ISP indica para qué direcciones de destino deben utilizarse como origen las direcciones asignadas. En este caso cada ISP indica que se puede alcanzar toda su red y toda la Internet.
El único router de salida (Re) recibe las asignaciones y las combina para luego distribuir la política combinada hacia los hosts utilizando una extensión del mensaje ND Router Advertisement, o bien la nueva opción DHCPv6 Source Address Selection Policy. Una vez que el host recibe las políticas las procesa y agrega a su tabla de políticas de selección de direcciones de origen.
Sin embargo esta propuesta tiene sus críticas pues es muy limitada en cuanto a las características de ingeniería de tráfico. En particular en el ejemplo de la Figura 21 se puede ver que al combinar las políticas no queda claro qué ISP utilizar para destinos alcanzados vía la ruta por defecto. Se está discutiendo cómo mejorarla para que sea posible balancear tráfico entre los distintos ISPs en forma escalable.
NAROS[editar]
El principio que propone NAROS es que cada vez que un host desee realizar una nueva comunicación consulte a un servidor que le indique qué dirección de origen debe utilizar. De esta forma la decisión se delega a una entidad que se supone tomará una decisión más inteligente que la que pudiese tomar el propio host.
En su algoritmo de selección de direcciones, un servidor NAROS puede integrar todo tipo de información que considere útil, por ejemplo:
- Políticas administrativas.
- Políticas de ingeniería de tráfico.
- Políticas de calidad de servicio.
- Acceso a información de encaminamiento provista por cada ISP vía BGP.
De esta forma es posible que el servidor NAROS induzca a los hosts a realizar balanceo de carga distribuyendo la misma en forma uniforme o no uniforme de acuerdo a alguna política fijada.
Con acceso a la información de encaminamiento de los ISPs el servidor también sería capaz de detectar fallas y no cursar tráfico por donde se están produciendo las mismas. Aunque vale la pena resaltar que NAROS no puede reestablecer ni preservar conexiones existentes, solo se limita a sugerir a los hosts qué direcciones de origen utilizar para realizar nuevas comunicaciones.
Una de las ventajas de NAROS es que sitúa la complejidad de la decisión en el servidor, liberando de esta tarea a los hosts. Sin embargo NAROS solo realiza sugerencias acerca de la mejor dirección de origen a utilizar. La decisión final sigue estando en manos de los hosts.
Para no generar mucho tráfico en la red ni sobrecargar al servidor NAROS con muchas preguntas las respuestas se almacenan en un caché hasta que el tiempo de vida especificado en las respuestas expira.
Otra ventaja de NAROS es que puede tomar decisiones complejas sin necesidad de distribuir tablas de políticas complejas que pueden ser un problema para hosts muy simples.
Naturalmente se plantea la preocupación acerca de la eficiencia y confiabilidad de realizar una consulta cada vez que se quiera establecer una nueva comunicación.
En cuanto a la eficiencia, los creadores de NAROS han realizado una serie de simulaciones de las cuales concluyen que no se impone una carga significativa al servidor.
En relación a la confiabilidad vale mencionar que el servidor NAROS podría utilizar una dirección anycast para brindar su servicio, facilitándose así la existencia de servidores NAROS redundantes.
La propuesta sugiere el uso del protocolo UDP como transporte para los mensajes NAROS, pero deja abierta la posibilidad a definir un nuevo mensaje ICMPv6 para transportar los mismos. El protocolo NAROS cuenta con dos mensajes: uno para efectuar solicitudes al servidor, y otro para que el servidor responda a las solicitudes.
Las solicitudes llevan los siguientes datos:
- Dirección de destino.
- Direcciones de origen disponibles, es decir las direcciones que tiene asignadas el cliente.
Las respuestas incluyen los siguientes datos:
- Mejor dirección de origen, que es entre las direcciones disponibles la que el servidor considera que debe utilizarse.
- Prefijo de destino para el cual el servidor considera que la mejor dirección de origen contenida en la respuesta es la que debe utilizarse.
- Un tiempo de vida que define por cuanto tiempo la información proporcionada en el mensaje puede ser cacheada.
La Figura 22 muestra a un servidor NAROS que tiene establecidas sesiones IBGP con todos los routers de salida. Con la información que puede obtener vía IBGP el servidor NAROS puede realizar una elección óptima del ISP de salida para cada comunicación.
Supongamos, por ejemplo, que el Host X desea establecer comunicación con el Host Y, entonces prepara un mensaje de consulta NAROS con los siguientes datos:
- Dirección de destino: D:Y
- Direcciones de origen disponibles: A:X1, B:X2 y C:X3
Al recibir la consulta el servidor NAROS evaluará en su base de datos de políticas cual es la mejor de las direcciones propuestas para comunicarse con D:Y. En este caso el servidor NAROS cuenta con acceso a la información de encaminamiento BGP, por lo que buscará en ella cual de los tres ISPs a los que se encuentra conectado el sitio es el mejor para comunicarse con D:Y. Esta selección la realiza con los criterios normales de BGP, aunque cabe la posibilidad de que se puedan tomar en cuenta otros datos en esa decisión. Supongamos que el servidor NAROS determina que el ISP-C es el mejor de los ISPs para conectarse con D:Y, luego armará y enviará al cliente un mensaje de respuesta como este:
- Mejor dirección de origen: C:C3
- Prefijo de destino: D:*
- Tiempo de vida: 300 segundos.
Con esta información el cliente podrá iniciar la comunicación utilizando como dirección de origen a C:X3. Además guardará por 300 segundos la información recibida y la utilizará no solo para comunicarse con el Host D:Y sino también con cualquier otro destino que se encuentre en el dominio del ISP-D. El tiempo de vida de 300 segundos ha sido propuesto en [NAROS] en base a una simulación del protocolo NAROS sobre tráfico real.
Comunicaciones entrantes[editar]
Como ya se ha descripto anteriormente es el host que inicia la comunicación quien en definitiva elige indirectamente al ISP por el que circularán los paquetes. En el caso de las conexiones iniciadas por un host remoto que desea comunicarse con un host interno al sitio con multihoming es ese host remoto el que toma la decisión al seleccionar la dirección IP de destino que utilizará para iniciar la comunicación. De modo que desde el sitio con multihoming no es posible obligarlo a realizar una determinada selección de direcciones, pero si es posible influir de alguna forma en su elección.
Por ejemplo, si se desea realizar balanceo de carga entre los distintos ISPs se puede influir en la decisión del host remoto a través del DNS. Por ejemplo respondiendo a las consultas de DNS con distintas direcciones para un mismo servicio. O alterando el orden de los registros de las respuestas de DNS de modo que el primer registro de cada respuesta vaya variando y pertenezca a distintos prefijos del sitio.
Si se contase con DNS dinámico que adaptara las respuestas al estado de la red se podría influir más inteligentemente en los hosts remotos.
Por ejemplo, supongamos que el servicio S, que estando alojado en el Host X, responde al nombre servicio.tld y cuenta con un par de registros AAAA correspondientes a las direcciones A:X1 y B:X2. Cuando el Host Y realice una consulta obtendrá, por ejemplo, el par de registros A:X1 y B:X2 en ese orden. Entonces el Host Y es probable que tome la primera dirección (A:X1) e intente comunicarse usándola. Si A:X1 es alcanzable para el Host Y entonces la comunicación utilizará esa dirección. Luego el Host Z también realiza la consulta por servicio.tld, pero en este caso el servidor de DNS responde con el par de registros en el orden B:X2 y A:X1, de modo que el Host Z intentará comunicarse usando la dirección B:X2.
También utilizando el DNS podría implementarse un servidor de DNS que respondiese un determinado porcentaje de consultas con la dirección correspondiente a un ISP y el resto con la dirección correspondiente al otro ISP. De forma que se lograría algún grado de control sobre el porcentaje de tráfico que se cursa para el servicio a través de cada ISP.
El borrador [NAROSD] propone también la utilización de NAROS en conjunto con el DNS para aplicar ingeniería de tráfico a las comunicaciones entrantes. La idea planteada es que el servidor de DNS que aloja la zona correspondiente al servicio al recibir una consulta se remita al servidor NAROS para determinar cual es la dirección que debiera usarse para la comunicación. El servidor NAROS, en base a la dirección de origen de la consulta DNS y a los distintos registros AAAA que contenga el nombre del servicio elegiría la dirección correcta, dirección que sería la primera que se incluiría en la respuesta DNS al cliente.
Selección de direcciones ante fallas[editar]
Si en la Figura 23 la conexión entre el ReA y RiA dejase de funcionar y el Host X intentase utilizar la dirección A:X1 para iniciar una comunicación con el exterior, ésta fallaría. Lo mismo sucedería si el Host Y intentase iniciar una comunicación con el Host A y eligiese a A:X1 como dirección de destino.
Ante este tipo de escenarios es pertinente analizar cómo deben reaccionar los mecanismos de selección de direcciones en el caso de que se produzcan fallas que alteren la topología de la red. En [ASIMH] se discuten posibles aproximaciones a la solución del problema. En particular se proponen mecanismos para complementar el algoritmo de selección de direcciones con el objeto de que la elección tenga en cuenta las posibles fallas que haya en la red en el momento de establecer las comunicaciones.
Selección de dirección de destino[editar]
Supongamos nuevamente que en la Figura 23 el enlace entre los routers ReA y RiA no funciona, y que un determinado servicio está siendo publicado en el DNS como alojado en el Host X, con direcciones A:X1 y B:X2. Si el Host Y desease comunicarse con el servicio y recibiese las direcciones A:X1 y B:X2 intentaría primero comunicarse con la dirección A:X1, comunicación que fallaría pues debiera pasar por el enlace RiA-ReA. En este caso siguiendo las indicaciones de RFC 3484 el Host Y intentaría comunicarse utilizando B:X2 como dirección de destino, y lograría establecer la comunicación. Por ello [ASIMH] concluye que no es necesario formular nuevas propuestas en este sentido.
Selección de dirección de origen[editar]
Donde si es necesario realizar propuestas es con respecto al algoritmo de selección de direcciones de origen especificado en RFC 3484. Esta especificación indica que en igualdad de condiciones debe elegirse la dirección de origen que tenga la mayor cantidad de bits iniciales en común con la dirección de destino. Esta decisión puede ser arbitraria, y no tiene en cuenta el estado de la red.
Un claro ejemplo se presenta en la Figura 23 donde a pesar de no estar operativo el enlace ReA-RiA es posible que el Host X se comunique con el Host Z siguiendo el camino Host X, ReB, RiB, ISP-B, Internet, ISP-A, Host Z. El algoritmo estándar de selección de direcciones al momento de seleccionar la dirección de origen para esta comunicación debiera elegir entre las direcciones A:X1 y B:X2, y elegiría A:X1 por ser esta la más parecida a la dirección de destino A:Z. Pero como esta elección implica que el tráfico debe pasar por el enlace ReA-RiA la comunicación sería imposible, luego es necesario contar con un método que le permita al host ser consciente de la situación y elegir B:X2 como dirección de origen en este caso.
Para estos casos en donde claramente el algoritmo de selección de direcciones estándar no es suficiente deben proponerse mecanismos que puedan elegir correctamente las direcciones de origen en caso de fallas.
Mecanismos proactivos
Estos mecanismos deben ser capaces de detectar los fallos en el momento que se producen y actuar en consecuencia, informando a los hosts de alguna forma para que estos no realicen elecciones de direcciones equivocadas.
- Fallas en enlaces directos entre el sitio y el ISP
Un escenario particular de falla se da cuando deja de funcionar el enlace del sitio con uno de sus ISPs, tal como se presenta en la Figura 23.
En este caso es el router de frontera el que cuenta con la información de primera mano acerca de la caída del enlace. Una vez detectado el problema es necesario notificar a los hosts para que no utilicen direcciones de origen correspondientes al ISP del enlace caído.
El borrador [ASIMH] propone utilizar el mensaje Neighbor Discovery Router Advertisement para realizar esta notificación. En particular propone utilizar el campo preferred de este mensaje el cual indica a los hosts por cuanto tiempo son preferidas las direcciones derivadas de un determinado prefijo. Mientras una dirección permanece en estado preferido el host puede utilizarla para establecer nuevas comunicaciones.
Entonces la idea es poner en cero el campo preferred, que indicará que las direcciones derivadas del prefijo no podrán ser utilizadas para establecer nuevas comunicaciones. Excluýendolas así del proceso de selección de direcciones de origen.
Esta solución es suficiente cuando se cuenta con un sitio compuesto por un solo enlace, donde los routers de salida pueden directamente generar los mensajes Router Advertisement. Pero si el sitio cuenta con muchos enlaces deberá buscarse una forma de notificar a todos los routers del sitio acerca de la novedad para que ellos puedan generar los mensajes Router Advertisement correspondientes. Para esta tarea se ha propuesto utilizar el protocolo Router Renumbering o DHCP.
- Otras fallas
Puede darse el caso en que haya una situación en que determinadas partes de Internet sean accesibles solamente vía determinados ISPs. Por ejemplo en la Figura 24 el ISP-A ha quedado aislado de Internet aunque desde el Sitio X se puede acceder a destinos internos al ISP-A. La situación en que se encuentra la red desde el punto de vista del Host X perteneciente al Sitio X es la siguiente:
- Solo es posible acceder a destinos internos al Sitio A (entre los que se incluye el Host Z) utilizando el enlace ReA-RiA, es decir utilizando como dirección de origen a A:X1
- Al resto de los destinos externos se debe acceder utilizando al ISP-B, es decir la dirección de origen B:X2.
Ante esta situación NAROS acude nuevamente al rescate. Al conocer el servidor NAROS que prefijos son accesibles por cada ISP podrá darse cuenta de la falla y sugerirá a los hosts iniciar las comunicaciones con las direcciones de origen correctas.
En el ejemplo de la Figura 24 si el Host X se quiere comunicar con el Host Y primero consultará al servidor NAROS, indicando que quiere comunicarse con la dirección D:Y y que tiene disponibles las direcciones de origen A:X1 y B:X2. El servidor NAROS consultará las tablas de encaminamiento BGP y determinará que la única forma de llegar en ese momento al ISP-D, cuyo prefijo es D:*, es a través de ISP-B, por lo que responderá sugiriendo el uso de la dirección B:X2 para comunicarse con cualquier destino correspondiente al prefijo D:*. Tomando esta sugerencia el host iniciará la comunicación usando la dirección B:X2.
Si el Host X quisiese comunicarse con el Host Z también consultará al servidor NAROS, el cual determinará que la única forma de alcanzar destinos alojados en ISP-A es a través del mismo ISP-A, por lo que habiendo recibido en la consulta el destino A:Z y los posibles orígenes A:X1 y B:X2 seleccionará a A:X1 para comunicarse con cualquier destino dentro del prefijo A:*. De esta forma se establecerá la comunicación aún cuando el ISP-A tenga problemas de encaminamiento en Internet.
Mecanismos reactivos
En vez de decidir cual será la dirección de origen a utilizar basándose en información sobre el estado del encaminamiento, como se ha descrito en los mecanismos proactivos, en los mecanismos reactivos el host probará con distintas direcciones de origen hasta lograr establecer la comunicación.
Luego de establecida la comunicación, la información acerca de la dirección de origen utilizada se almacena en un caché de direcciones de origen.
Hay una entrada en este caché de direcciones de origen para cada una de las direcciones de destino. Las entradas están compuestas por los siguientes campos:
- Dirección de Destino (clave para búsquedas)
- Dirección de Origen a utilizar
- Tiempo de vida
Al ser este un mecanismo de prueba y error, el cache permite que una vez que establecida comunicación con un destino, no sea necesario repetir el proceso por un tiempo.
En la Figura 25 se ilustra el proceso de creación y actualización de las entradas del caché cada vez que arriba un paquete.
Queda pendiente quien y cómo realizará las pruebas de direcciones de origen. Los mecanismos propuestos son:
- Que las capas superiores a IP se encarguen de realizar los reintentos. En este caso sería la capa IP la que debiera usar una dirección de origen distinta para cada reintento si es que no hay ya una dirección almacenada en el caché.
- Que sea la misma capa IP la que se encargue de realizar los reintentos. Este mecanismo presenta muchos inconvenientes pues la capa IP debe almacenar los paquetes que ha enviado mientras no haya una entrada en el caché. Esto es así porque mientras no exista esa entrada la capa IP deberá reenviar el paquete usando distintas direcciones de origen. Además se requiere de una serie de temporizadores para que IP determine que debe reenviar un paquete, lo que complica la implementación, sumado al problema de que IP no es capaz de reconocer certeramente que paquetes entrantes son respuesta a los salientes.
- Que se intente con todas las direcciones de origen simultáneamente. Es decir que cuando la capa IP recibe un paquete desde una capa superior, si no encuentra una entrada para el destino en el caché entonces envía tantos paquetes como direcciones de origen tenga. Al recibir la primera respuesta se creará la entrada correspondiente en el caché y se usará esa dirección en lo sucesivo. Un efecto colateral de este mecanismo es que se tiende a seleccionar la dirección con menor retardo de ida y vuelta, pero con la desventaja de que se genera más tráfico al enviar múltiples paquetes.