4 research outputs found

    D3.6.1: Cookbook for IPv6 Renumbering in SOHO and Backbone Networks

    Get PDF
    In this text we present the results of a set of experiments that are designed to be a first step in the process of analysing how effective network renumbering procedures may be in the context of IPv6. An IPv6 site will need to get provider assigned (PA) address space from its upstream ISP. Because provider independent (PI) address space is not available for IPv6, a site wishing to change provider will need to renumber from its old network prefix to the new one. We look at the scenarios, issues and enablers for such renumbering, and present results and initial conclusions and recommendations in the context of SOHO and backbone networking. A subsequent deliverable (D3.6.2) will refine these findings, adding additional results and context from enterprise and ISP renumbering scenarios

    Herramientas para la conectividad IPv6 con múltiples proveedores

    Get PDF
    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

    Improving end-to-end availability using overlay networks

    Get PDF
    Thesis (Ph. D.)--Massachusetts Institute of Technology, Dept. of Electrical Engineering and Computer Science, February 2005.Includes bibliographical references (p. 139-150).The end-to-end availability of Internet services is between two and three orders of magnitude worse than other important engineered systems, including the US airline system, the 911 emergency response system, and the US public telephone system. This dissertation explores three systems designed to mask Internet failures, and, through a study of three years of data collected on a 31-site testbed, why these failures happen and how effectively they can be masked. A core aspect of many of the failures that interrupt end-to-end communication is that they fall outside the expected domain of well-behaved network failures. Many traditional techniques cope with link and router failures; as a result, the remaining failures are those caused by software and hardware bugs, misconfiguration, malice, or the inability of current routing systems to cope with persistent congestion.The effects of these failures are exacerbated because Internet services depend upon the proper functioning of many components-wide-area routing, access links, the domain name system, and the servers themselves-and a failure in any of them can prove disastrous to the proper functioning of the service. This dissertation describes three complementary systems to increase Internet availability in the face of such failures. Each system builds upon the idea of an overlay network, a network created dynamically between a group of cooperating Internet hosts. The first two systems, Resilient Overlay Networks (RON) and Multi-homed Overlay Networks (MONET) determine whether the Internet path between two hosts is working on an end-to-end basis. Both systems exploit the considerable redundancy available in the underlying Internet to find failure-disjoint paths between nodes, and forward traffic along a working path. RON is able to avoid 50% of the Internet outages that interrupt communication between a small group of communicating nodes.MONET is more aggressive, combining an overlay network of Web proxies with explicitly engineered redundant links to the Internet to also mask client access link failures. Eighteen months of measurements from a six-site deployment of MONET show that it increases a client's ability to access working Web sites by nearly an order of magnitude. Where RON and MONET combat accidental failures, the Mayday system guards against denial- of-service attacks by surrounding a vulnerable Internet server with a ring of filtering routers. Mayday then uses a set of overlay nodes to act as mediators between the service and its clients, permitting only properly authenticated traffic to reach the server.by David Godbe Andersen.Ph.D

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

    Get PDF
    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
    corecore