Multi-homing tunnel broker

A proper support for communications has to provide fault tolerance capabilities such as the preservation of established connections in case of failures. Multihoming addresses this issue, but the currently available solution based in massive BGP route injection presents serious scalability limitations, since it contributes to the exponential growth of the BGP table size. An alternative solution based on the configuration of tunnels between the multihomed site exit routers and the ISP border routers has been proposed for IPv6 in RFC 3178. However, the amount of manual configuration imposed by this solution on the ISP side prevents its wide adoption. In particular, this solution requires at the ISP the manual configuration of a tunnel endpoint per each multihomed client that it serves. We present a multihoming tunnel broker (MHTB) that provides automatic creation of the tunnel endpoint at the ISP side.This work was supported by the SAM (Advanced Servers with Mobility)project, funded by the Spanish National research and Development Programme as TIC2002-04531-C04-03.Publicad

A QoS-Driven ISP Selection Mechanism for IPv6 Multi-homed Sites

A global solution for the provision of QoS in IPng sites must include ISP selection based on per-application requirements. In this article we present a new site-local architecture for QoS-driven ISP selection in multi-homed domains, performed in a per application basis. This architecture proposes the novel use of existent network services, a new type of routing header, and the modification of address selection mechanisms to take into account QoS requirements. This proposal is an evolution of current technology, and therefore precludes the addition of new protocols, enabling fast deployment. The sitelocal scope of the proposed solution results in ISP transparency and thus in ISP independency.This research was supported by the LONG (Laboratories Over the Next Generation Networks) project IST-1999-20393.Publicad

Preserving Established Communications in IPv6 Multi-homed Sites with MEX

This research was supported by the SAM (Advanced Mobility Services) project, funded by the Spanish National R&D Programme under contract MCYT TIC2002-04531-C04-03.A proper support for multimedia communications transport has to provide fault tolerance capabilities such as the preservation of established connections in case of failures. While multi-homing addresses this issue, the currently available solution based in massive BGP route injection presents serious scalability limitations, since it contributes to the exponential growth of the BGP table size. Alternative solutions proposed for IPv6 fail to provide equivalent facilities to the current BGP based solution. In this paper we present MEX (Muti-homing through EXtension header) a novel proposal for the provision of IPv6 multi-homing capabilities. MEX preserves overall scalability by storing alternative route information in end-hosts while at the same time reduces packet loss by allowing routers to re-route in-course packets. This behavior is enabled by conveying alternative route information within packets inside a newly defined Extension Header. The resulting system provides fault tolerance capabilities and preserves scalability, while the incurred costs, namely deployment and packet overhead, are only imposed to those that benefit from it. An implementation of the MEX host and router components is also presented.Publicad

A report on IPv6 deployment activities and issues at Sandia National Laboratories:FY2007.

Internet Protocol version 4 (IPv4) has been a mainstay of the both the Internet and corporate networks for delivering network packets to the desired destination. However, rapid proliferation of network appliances, evolution of corporate networks, and the expanding Internet has begun to stress the limitations of the protocol. Internet Protocol version 6 (IPv6) is the replacement protocol that overcomes the constraints of IPv4. As the emerging Internet network protocol, SNL needs to prepare for its eventual deployment in international, national, customer, and local networks. Additionally, the United States Office of Management and Budget has mandated that IPv6 deployment in government network backbones occurs by 2008. This paper explores the readiness of the Sandia National Laboratories network backbone to support IPv6, the issues that must be addressed before a deployment begins, and recommends the next steps to take to comply with government mandates. The paper describes a joint work effort of the Sandia National Laboratories ASC WAN project team and members of the System Analysis & Trouble Resolution, the Communication & Network Systems, and Network System Design & Implementation Departments

Study of the operation of a network implemented in the ipv6 protocol

Internet se ha convertido en un recurso crítico para el funcionamiento de más y más instituciones de diversa naturaleza. Lejos están ya los días en que sólo las empresas relacionadas directamente con las tecnologías de la información eran las únicas para las cuales el acceso a Internet resultaba imprescindible para su operación. Hoy en día instituciones de toda naturaleza y tamaño requieren conectividad global ya sea para proveer servicios a través de Internet, para relacionarse con sus proveedores e incluso para el funcionamiento cotidiano de las operaciones internas. Esto implica que una interrupción en el acceso a Internet supone un alto costo, por lo que existe una fuerte demanda de mecanismos que brinden un alto nivel de tolerancia a fallos en la conexión a Internet. El Protocolo de Internet define como se comunican los dispositivos a través de las redes. La versión 4 de IP (IPv4), que actualmente es predominante, contiene aproximadamente cuatro mil millones de direcciones IP, las cuales no son suficientes para una duración ilimitada. Dicho agotamiento del espacio fue realidad en el 2011. Esto está afectando el negocio de los ISPs existentes, llegando en cierto punto, a la creación de nuevas ISPs. Como una de las consecuencias, puede tener un impacto más profundo en las regiones en desarrollo (África, Asia y América latina/el Caribe) donde no está todavía tan extensa la penetración de Internet. El crecimiento extraordinario de las nuevas tecnologías y, en especial, la implementación del Protocolo IP en su versión 6 (IPv6) abre un enorme abanico de posibilidades, actividades y nuevas formas de comunicarse, trabajar, comprar, relacionarse con otras personas y, en definitiva, desempeñar las tareas cotidianas de nuestra vida. El propósito de este estudio es aportar una serie de conocimientos básicos de carácter técnico, necesarios para conocer IPv6, su funcionamiento y el estado actual de su implementación a nivel mundial para, posteriormente, entrar a conocer los posibles problemas y soluciones, en una red nativa en la Universidad de Pamplona.INTRODUCCION 9 1. PLANTEAMIENTO DEL PROBLEMA 13 1.1. PLANTEAMIENTO 13 1.2. JUSTIFICACIÓN 15 1.3. HIPÓTESIS 16 1.4. OBJETIVOS 16 1.4.1 Objetivo principal 16 1.4.2 Objetivos específicos 17 1.5. METODO 18 2. REVISIÓN DE LITERATURA 19 2.1 Estado del arte TCP/IP. 20 2.1.1 Fuentes Primarias – Trabajos Relacionados. 23 2.1.1.1 Internacional. 23 2.1.1.2 Nacional. 27 2.2 Estado del arte IPv4. 30 2.2.1 Fuentes Primarias – Trabajos Relacionados. 30 2.2.1.1 Internacional. 30 2.2.1.2 Nacional. 34 2.3 Estado del arte IPv6. 35 2.3.1 Fuentes Primarias – Trabajos Relacionados. 35 2.3.1.1 Internacional. 35 2.3.1.2 Nacional. 44 2.4. RFC (Request For Comments) 46 2.4.1 RFC generales 46 2.4.2 RFC Calidad de servicio QoS 53 2.4.3 RFCs Relacionados con calidad de servicio QoS 55 2.4.4 RFC 3775 61 RESULTADOS 63 3. SERVICIOS: LABORATORIOS DE LOS PROTOCOLOS TCP (PROTOCOLO DE CONTROL DE TRANSMISIÓN) E IP (PROTOCOLO DE INTERNET) 63 3.1. SOFTWARE: SISTEMAS OPERATIVOS, APLICACIONES 63 3.1.1 Acceso al servidor Web con direcciones Locales de Sitio 64 3.1.2 Prueba de la comunicación entre dos equipos con IPv6 65 3.1.3 Prueba del servidor Apache httpd-2.2.3 66 3.1.4 Pruebas del servidor DNS 66 3.1.4.1 Comando netstat 67 3.1.4.2 Comando nslookup 67 3.1.5 Prueba de eficiencia de un servidor DNS con direcciones IPv4 e IPv6 68 3.1.6 Pruebas de sockets con direcciones IPv4 e IPv6 70 3.1.7 Criterios de Asignación de Direcciones IPv6 71 3.2. Laboratorio Nº 1: Instalar la Versión 6 de IP en Windows XP 72 3.3. Laboratorio Nº 2: Prueba de la Conectividad entre Hosts Locales del Vínculo 75 3.4. Laboratorio Nº 3: Comunicación a un Servidor Web con Direcciones IPv6 Locales del Sitio 77 3.5. Laboratorio Nº 4: Comunicación Remota con SSH (Protocolo de Intérprete Seguro) entre dos Host con Direcciones IPV6 Locales del Sitio 79 3.6. Laboratorio Nº 5: Configuración de un Servidor DNS (Servicio de Nombres de Dominio) con Direcciones IPV6 Locales Del Sitio 85 3.7. Laboratorio Nº 6: Realización de Sockets bajo JAVA con Direcciones IPV6 Locales del sitio 96 4. IPSec 104 4.1. Descripción del Protocolo IPSec 104 4.1.1 Asociación de Seguridad SA (Security Association) 105 4.1.2 Modos de Operación en IPSEC 106 4.2. Métodos de Seguridad en IPSEC 107 4.3. PRUEBAS REALIZADAS CONFIGURACIÓN No1 108 4.3.1 Configuración General 108 4.3.2 Configuración de IPv6 en un Equipo Red Hat Linux 9 108 4.3.2.1 Configuración IPv6 109 4.3.3 Configuración y Prueba de IPSec para IPv6 113 4.3.3.1 Instalación de Frees/wan 113 4.4. PRUEBAS REALIZADAS CONFIGURACIÓN No2 118 4.4.1 Implementación y medición del tráfico de datos de IPSec en IPv6 118 4.4.2 Dispositivos empleados para la configuración de IPSec en IPv6 119 4.4.3 Tráfico de datos de IPSec en IPv6 120 4.4.3.1 Diseño de la red 120 4.4.3.2 Configuración de la red 120 4.4.3.3 Utilizar IPSec entre dos hosts del vínculo local (FE80) y local de sitio (FC80) 121 4.4.3.4 Cómo configurar las políticas de seguridad IPSec y las asociaciones de seguridad para IPv6 127 4.4.3.5 Captura y análisis de tráfico 127 4.4.3.6 Captura y análisis de tráfico 140 4.4.3.7 Análisis comparativo del tráfico de datos sin IPSEC habilitado 153 4.4.3.8 Análisis comparativo del tráfico de datos con IPSEC habilitado 154 5. QoS 155 5.1 INTRODUCCIÓN 155 5.2 ANTECEDENTES DE DESARROLLO QoS 156 5.2.1 Nacional 156 5.2.2 Internacional 157 5.3. CONCEPTOS GENERALES 158 5.3.1 ICMPv6 159 5.3.3 Calidad de servicio 160 5.3.3.1 Componentes de la calidad de servicio 160 5.3.3.2 Campos de la cabecera IPv6 162 5.3.3.3 Herramienta Oreneta: captura, filtra y representa los flujos en tiempo real 163 5.3.3.3.1 Sincronización de las sondas 163 5.3.3.3.2 Captura pasiva 164 5.3.3.3.3 Filtrado 164 5.3.3.3.4 Representación de los flujos 164 5.4. PRUEBAS DE CALIDAD DE SERVICIO QoS SOBRE UNA RED IPv6 164 5.4.1 Configuración de la red 165 5.4.1.1 Topología 165 5.4.1.2 Configuración de IPv6 165 5.4.1.3 Asignación de direcciones IPv6 167 5.4.1.4 Configuración del router 168 5.4.2 Configuración de Calidad de Servicio 170 5.4.3 Captura y análisis del control de tráfico de datos 176 6. ANÁLISIS DE MOVILIDAD EN EL PROTOCOLO DE INTERNET VERSIÓN 6 (MIPv6) 183 6.1. INTRODUCCIÓN 183 6.2. ESTADO DEL ARTE 183 6.2.1 Movilidad IPv6 (MIPv6) 183 6.3. MOVILIDAD IPv6 188 6.3.1 Terminología de MIPv6 188 6.3.2 Visión general de MIPv6 189 6.3.2.1 Actualización de uniones y reconocimientos 194 6.3.2.2 Actualizando Enlaces 199 6.3.2.3 Detección de movimiento 200 6.3.2.4 Retorno a Home 204 6.3.2.5 Selección de dirección fuente en nodos móviles 206 6.3.2.6 Detección de cambios en el enlace primario 209 6.3.2.7 Que sucede si el agente primario falla? 209 6.3.2.8 Nodos móviles con más de un agente 210 6.3.2.9 Enlaces virtuales primarios 210 6.4. OPTIMIZACIÓN DE RUTA 211 6.4.1 Enviando paquetes optimizados al nodo correspondiente 213 6.4.2 Reconociendo BU´s enviados a nodos móviles 215 6.4.3 Que sucede si el nodo correspondiente falla 216 6.5. COMUNICACIÓN EJEMPLO 217 6.6. SIMULACIÓN 219 6.6.1 El Simulador: Network Simulator 219 6.6.2 Descripción de la herramienta 220 6.6.2.1 Event Scheduler Object 221 6.6.2.2 Network Component object 222 6.6.2.3 Network Setup Helping Module 223 6.6.2.4 Nam (Network Animator) 224 6.6.2.5 Xgraph 225 6.6.3 Instalación del Network Simulator 225 6.6.4 Escenario propuesto 228 6.6.5. Creando la topología 229 6.6.5.1 Creación de la topología de MIPv6 229 6.6.5.2 Finalizando la simulación 230 6.6.6 Corriendo la simulación 231 6.6.7 Trazas 232 7. DISCUSIÓN 234 8. RECOMENDACIONES/CONCLUSIONES 235 9. REFERENCIAS Y BIBLIOGRAFÍA 237 9.1 PRINCIPALES 237 9.2 SECUNDARIAS 237 9.3 DIRECCIONES URL 238MaestríaThe Internet has become a critical resource for the functioning of more and more institutions of diverse nature. Gone are the days when only companies directly related to information technology were the only ones for which Internet access was essential for their operation. Today, institutions of all kinds and sizes require global connectivity, either to provide services through the Internet, to interact with their suppliers and even for the daily functioning of internal operations. This implies that an interruption in Internet access involves a high cost, so there is a strong demand for mechanisms that provide a high level of fault tolerance in the Internet connection. The Internet Protocol defines how devices communicate over networks. IP version 4 (IPv4), which is currently prevalent, contains approximately four billion IP addresses, which are not sufficient for an unlimited duration. This depletion of space was a reality in 2011. This is affecting the business of existing ISPs, reaching a certain point, to the creation of new ISPs. As one of the consequences, it may have a more profound impact in developing regions (Africa, Asia and Latin America / the Caribbean) where Internet penetration is not yet as extensive. The extraordinary growth of new technologies and, especially, the implementation of the IP Protocol in its version 6 (IPv6) opens a huge range of possibilities, activities and new ways of communicating, working, shopping, interacting with other people and, ultimately , carry out the daily tasks of our life. The purpose of this study is to provide a series of basic knowledge of a technical nature, necessary to know IPv6, its operation and the current state of its implementation worldwide, to later learn about possible problems and solutions in a native network at the University of Pamplona

Herramientas para la conectividad IPv6 con múltiples proveedores

La presente Tesis propone una arquitectura para la provisión de una solución de multihoming escalable y de la exploración de distintos enfoques. La solución actualmente disponible en IPv4 para el soporte de multihoming basada en la inyección de rutas de sitio en el sistema global de rutas impone una carga que crece linealmente con el número de sitios multihomed, lo que limita su escalabilidad y las posibilidades de crecimiento. La presente Tesis plantea una solución alternativa que garantice la escalabilidad del sistema global de rutas basada en el uso de direcciones agregables por proveedor (PA). En una configuración basada en direcciones PA, un sitio multihomed obtiene tantos bloques de dirección como proveedores tiene lo que plantea las dificultades con los filtros de ingreso, con el iniciar una nueva comunicaciones después de un fallo y la preservación de comunicaciones ante la ocurrencia de un fallo. La presente Tesis Doctoral plantea una arquitectura para solventar estos problemas basada en el encaminamiento basado en dirección origen para proveer compatibilidad con los filtros de ingreso, y una nueva capa de identificación dentro de la capa IP para brindar las capacidades requeridas de tolerancia de fallos. ________________________________________________In this Thesis we propose an architecture for the provision of scalable IPv6 multihoming support. In the multihoming solution currently deployed in the IPv4 Internet, the multihomed site announces a route to its address blocks through all the providers using BGP. The result is that multiple routes towards the multihomed site are available in the inter-domain routing system. While this solution provides the fault tolerance and path selection features required to a multihoming solution, it presents limited scalability, since each multihomed site contributes with at least one routing table entry in the already oversized inter-domain routing tables. Because the support of the multihoming solution currently deployed in the IPv4 Internet is becoming challenging even for the current number of multihomed sites, this approach is deemed unsuitable for the expected number of multihomed sites in the future IPv6 Internet, especially when considering that the wide adoption of low-budget broadband access technologies such as ADSL or CATV will enable multihoming in SOHO environments. As a consequence, an alternative multihoming solution for IPv6 is needed. The requirements imposed to the new solution essentially include all the benefits provided by the incumbent solution, i.e. fault tolerance and traffic engineering capabilities, and also an enhanced scalability with respect to the number of multi-homed sites and other relevant Internet parameters. In order to preserve routing system scalability, aggressive route aggregation can be achieved through provider-based aggregation, precluding the injection of routes associated with individual multi-homed end-sites. When Provider Aggregatable (hereafter PA) addressing is used, multi-homed sites obtain one prefix per each one of their providers. Consequently, as each provider will only announce its own prefix to the rest of the Internet, a given provider will be used to reach the multihomed site only when the destination addresses used belong to the prefix associated with the provider. So, in order to be reachable through all of the providers of the site, each host within the multihomed site will have to configure multiple addresses, one per provider. Even if this setup guarantees the scalability of the multihoming solution, such multi-addressed configuration is not without difficulties of its own when attempting to provide the additional features mentioned above. In particular, this configuration presents the following problems: - Incompatibility with ingress filtering techniques: The incompatibility is caused by the lack of coordination between the IPv6 source address selection mechanism, performed by the host, and the path selection mechanism, performed by the intra-site routing system. As long as outgoing packets are routed through the provider that has delegated the prefix contained in the source address, packets will flow freely; but when those packets are routed through a different ISP, they will be discarded by the ingress filtering mechanism x due to source address incompatibility. It must be noted that because of this issue, packets may be discarded even in a scenario without failures. - Difficulties when establishing new communications after an outage. The difficulties arise because not all of the addresses available for a multihomed host are reachable, so in order to be able to communicate, hosts need to properly discard unreachable addresses and select those addresses that are reacahable. Current address selection mechanisms are unable to cope with such situation. - Difficulties when preserving established communications. In order to preserve established communications through outages, the endpoints of the communication have to adapt the addresses used during the lifetime of the communication according to the available providers. Moreover, this address replacement has to be performed in a transparent fashion with respect to transport and application layers, in order to actually preserve the established communication. Current applications and transport layers, such as TCP and UDP, identify the endpoints of a communication through the IP addresses of the nodes involved, implying that the IP addresses selected at the communication establishment time must remain invariant through the lifetime of the communication. But as it has been presented earlier, once that an outage has occurred in one of the available ISPs, the associated address becomes unreachable, so an alternative address has to be used in order to convey packets to the multi-homed host. These two constraints impose that after an outage, packets must carry a different address, corresponding to an available ISP, but they have to be presented to transport and application layers as if they contained the original address, in order to be recognized as belonging to the established communication. Such approach requires additional mechanisms in both ends of the communication in order to preserve a coherent mapping between the IP addresses presented to the transport and application layers and those addresses actually contained in the packets. - Difficulties when providing traffic engineering capabilities. The usage of multiple prefixes pre multihomed site imply that those traffic engineering techniques will no longer apply, and alternative mechanisms that provide equivalent capabilities are required. In this Thesis we describe an architecture for the provision of multihoming in IPv6 that deals with all the aforementioned concerns. The proposed IPv6 multihoming architecture introduces the following components: - An intra-site routing paradigm that takes into account the source address, so that source hosts can determine through the selection of the source address, the exit path of the packets. Such feature provides ingress filtering compatibility. - An address selection mechanism that takes into account address reachability information acquired through a trial and error procedure. - A new Multihoming Sub-Layer within the IP layer that will perform the required mapping between the addresses that are presented to the upper layer protocols and the addresses that are actually used for exchanging packets in the network. Such layer allows the usage of different addresses for exchanging packets during the lifetime of a communication, while keeping unchanged the address presented to the upper layers, preserving the established communication. - A mechanism for the configuration of the policy table defined in the default address selection procedure, for the provision of traffic engineering capabilities. A detailed presentation of the aforementioned mechanisms is preceded by an exhaustive analysis of the solution space that justifies the selected approach