An API for IPv6 Multihoming

IFIP International Workshop on Networked Applications, Colmenarejo, Madrid/Spain, 6?8 July, 2005This paper proposes an API for Multihoming in IPv6. This API is based on the Hash Based Addresses and Cryptographically Generated Addresses approaches, which are being developed by the IETF multi6 Working Group. The support of Multihoming implies several actions such as failure detection procedures, reachability tests, re-homing procedures and exchange of locators. Applications can benefit from transparent access to Multihoming services only if per host Multihoming parameters are defined. However, more benefits could be obtained by applications if they will be able to configure these parameters. The proposed Multihoming API provides different functions to applications which can modify some parameters and invoke some functions related with the Multihoming Layer.Publicad

An API for IPv6 Multihoming based on HBA and CGA

EUNICE 2005. IFIP International Workshop on Networked Applications, Colmenarejo, Madrid/Spain, 6–8 July, 2005. (Proceedings of the 11th Open European Summer School EUNICE 2005: Networked Applications)This paper proposes an API for Multihoming in IPv6. This API is based on the Hash Based Addresses and Cryptographically Generated Addresses approaches, which are being developed by the IETF multi6 Working Group. The support of Multihoming implies several actions such as failure detection procedures, reachability tests, re-homing procedures and exchange of locators. Applications can benefit from transparent access to Multihoming services only if per host Multihoming parameters are defined. However, more benefits could be obtained by applications if they will be able to configure these parameters. The proposed Multihoming API provides different functions to applications which can modify some parameters and invoke some functions related with the Multihoming Layer.This work has been partly supported by the European Union under the E-Next Project FP6506869 and by OPTINET6 project TIC-2003-09042-C03-01

Efficient security for IPv6 multihoming

In this note, we propose a security mechanism for protecting IPv6 networks from possible abuses caused by the malicious usage of a multihoming protocol. In the presented approach, each multihomed node is assigned multiple prefixes from its upstream providers, and it creates the interface identifier part of its addresses by incorporating a cryptographic one-way hash of the available prefix set. The result is that the addresses of each multihomed node form an unalterable set of intrinsically bound IPv6 addresses. This allows any node that is communicating with the multihomed node to securely verify that all the alternative addresses proposed through the multihoming protocol are associated to the address used for establishing the communication. The verification process is extremely efficient because it only involves hash operationsPublicad

Transición al protocolo IPV6, aspectos de seguridad informática para tener presente.

El siguiente trabajo está enfocado en el estudio de los pasos necesarios para lograr un proceso de migración del protocolo IPV4 al protocolo IPV6 de manera exitosa, mencionando las herramientas necesarias a implementar, buscando que la transición se logre de una forma transparente, evitando complicaciones en los servicios de la entidad que desea realizar la actualización; esto con el fin de dar solución a las múltiples problemáticas que se han evidenciado en el protocolo IPV4, problemáticas que generan un atraso e impiden el uso de nuevas aplicaciones que son fundamentales para la evolución de los procesos de comunicación. El nuevo protocolo se presenta como solución y forma de subsanar las falencias que su antecesor ha dejado en evidencia. Comprendiendo que este proceso de migración tiene su grado de complejidad, se requiere de una rigurosa investigación y conceptualización, por tal motivo se presenta la siguiente monografía con el fin de guiar de forma correcta en el curso de la transición. En este escrito, se plantean fases básicas las cuales buscan que la migración se logre con la mayor transparencia posible, pensando en la normalidad de los procesos de la empresa que asuma el reto, cada fase cuenta con una serie de actividades que incorporándolas en un cronograma dará vía al cambio entre el IPV4 e IPV6. Cada entidad podrá tomar como base estas fases y sus respectivas actividades para la construcción de un cronograma, este será ajustado a la necesidad de la compañía, sin saltar procesos que pudieran ser vitales para la adopción del protocolo IPV6.The following work is focused on the explanation of the steps necessary to achieve a process of migration of the IPV4 protocol to the IPV6 protocol in a successful way, mentioning the necessary tools to be implemented, looking for the transition to be achieved in a transparent way, avoiding complications in the services of the entity that wishes to perform the update; this in order to solve the multiple problems that have been evidenced in the IPV4 protocol, problems that generate a delay and prevent the use of new applications that are fundamental for the evolution of communication processes. The new protocol is presented as a solution and way of correcting the shortcomings that its predecessor has left in evidence. Understanding that this migration process has its degree of complexity, a rigorous investigation and conceptualization is required, for this reason the following monograph is presented in order to guide correctly during the transition. In this paper, basic phases are proposed which seek that migration be achieved with the greatest possible transparency, thinking about the normality of the company's processes that take on the challenge, each phase has a series of activities that incorporating them into a schedule will give way to the change between IPV4 and IPV6. Each entity may take as a basis these phases and their respective activities for the construction of a schedule, this will be adjusted to the need of the company, without skipping processes that could be vital for the adoption of the IPV6 protocol

Multihoming with ILNP in FreeBSD

Multihoming allows nodes to be multiply connected to the network. It forms the basis of features which can improve network responsiveness and robustness; e.g. load balancing and fail-over, which can be considered as a choice between network locations. However, IP today assumes that IP addresses specify both network location and node identity. Therefore, these features must be implemented at routers. This dissertation considers an alternative based on the multihoming approach of the Identifier Locator Network Protocol (ILNP). ILNP is one of many proposals for a split between network location and node identity. However, unlike other proposals, ILNP removes the use of IP addresses as they are used today. To date, ILNP has not been implemented within an operating system stack. I produce the first implementation of ILNP in FreeBSD, based on a superset of IPv6 – ILNPv6 – and demonstrate a key feature of ILNP: multihoming as a first class function of the operating system, rather than being implemented as a routing function as it is today. To evaluate the multihoming capability, I demonstrate one important application of multihoming – load distribution – at three levels of network hierarchy including individual hosts, a singleton Site Border Router (SBR), and a novel, dynamically instantiated, distributed SBR (dSBR). For each level, I present empirical results from a hardware testbed; metrics include latency, throughput, loss and reordering. I compare performance with unmodified IPv6 and NPTv6. Finally, I evaluate the feasibility of dSBR-ILNPv6 as an alternative to existing multihoming approaches, based on measurements of the dSBR’s responsiveness to changes in site connectivity. We find that multihoming can be implemented by individual hosts and/or SBRs, without requiring additional routing state as is the case today, and without any significant additional load or overhead compared to unicast IPv6

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