4 research outputs found
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