Análisis del protocolo Ipv6 su evolución y aplicabilidad

El cambio de Internet 4 a Internet 6 es necesario conforme el espacio de direcciones asignables se reduce y crecen los sitios y aplicaciones que requieren les sea asignada una IP propia, por lo tanto es necesario que desde ya se empiece a desarrollar una metodología de migración en las redes locales, al igual que se desarrolla políticas de seguridad, de compartición de recursos, etc.Descripción de IPv4.- Organización de internet.- Modelo de referencia OSI frente a TCP/IP.- Problemas con IPv4.- Historia del IPv6.- Características de IPv6.- Notación IPv6.- Tipos de direcciones IPv6.- Datagrama IPv6.- DNS para IPv6.- principales protocolos en IPv6.- Seguridad en IPv6.- Organización administradores, políticas de distribución y asignación de direcciones Ipv6.- Funciones de DSTM.- Túneles .- Traductores.- Implementación de una isla IPv6 y conexión con el 6bone

Estudi d'implantació de la IPv6 al CTTC

In recent years, the number of devices connected to Internet has increased exponentially and in fact, it is estimated that the demand keep on increasing. When IPv4 protocol was introduced, this evolution was not expected. Over the years several limitations have arosen, including scalability and the unsustainable growth of the Internet routing table. In the late 90s, IPv6 protocol was defined to solve these issues and add new features. Currently, the Centre Tecnològic de Telecomunicacions de Catalunya (CTTC) has been forced to propose IPv6 deployment on its network mainly caused by the IPv4 address depletion, the increasing demand for devices connectivity and the need to support IPv6. RedIris and CSUC are encouraging and supporting the affiliated institutions like CTTC to deploy IPv6. This project is carried out by the IT department of CTTC, the Centre de Serveis Informàtics (CSI). The purpose of this project is, on the one hand, to analyse and acknowlege the main features of IPv6 protocol and show the differences with IPv4. It also aims to implement native IPv6 network in CTTC. On the other hand, the CTTC needs to give support with IPv6 in some basic services like DNS and web services. Finally, it is thought to compare IPv6 and IPv4 performance on the CTTC network. We analysed the network equipment and the network topology before proposing an IPv6 compatible solution. This causes the replacement of some network equipment. To gradually integrate IPv6 in the CTTC network we have chosen the dual-stack deployment. IPv6 is deployed in parallel with IPv4 on all infrastructure and services. We are adapting the DNS and the website service to IPv6 requests. In this project we are measuring the performance of IPv6 versus IPv4. We are running some tests to evaluate the performance through the calculation of the Round-Trip Time (RTT), throughput and Time To First Byte (TTFB) parameters. The results of the performance tests in the CTTC network are not showing important differences between the two protocols. The RTT is larger in IPv6, the throughput is higher in IPv4 and the TTFB depends on if the dual stack is enabled. The network latency is lower in IPv6 on a dual stack scenario. However, when there is only one protocol set the result is opposite. Thedistance between the origin and the destination of communications is relevant because this affects the latency of the connection. This is due to the number of hops to destination, the network type and the service provided. In another test, we are comparing IPv6 with NAT (Network Address Translation) to evaluate this alternative method as a solution to the IPv4 address depletion. The results obtained in the comparison are quite similar

Developing the Fringe Routing Protocol

An ISP style network often has a particular traffic pattern not typically seen in other networks and which is a direct result of the ISP’s purpose, to connect internal clients with a high speed external link. Such a network is likely to consist of a backbone with the clients on one ‘side’ and one or more external links on the other. Most traffic on the network moves between an internal client and the external world via the backbone. But what about traffic between two clients of the ISP? Typical routing protocols will find the ‘best’ path between the two gateway routers at the edge of the client stub networks. As these routers connect the stubs to the ISP core, this route should be entirely within the ISP network. Ideally, from the ISP point of view, this traffic will go up to the backbone and down again but it is possible that it may find another route along a redundant backup path. Don Stokes of Knossos Networks has developed a protocol to sit on the client fringes of this ISP style of network. It is based on the distance vector algorithm and is intended to be subordinate to the existing interior gateway protocol running on the ISPs backbone. It manipulates the route cost calculation so that paths towards the backbone become very cheap and paths away from the backbone become expensive. This forces traffic in the preferred direction unless the backup path ‘shortcut’ is very attractive or the backbone link has disappeared. It is the analysis and development of the fringe routing protocol that forms the content of this ME thesis