Case Study - IPv6 based building automation solution integration into an IPv4 Network Service Provider infrastructure

The case study presents a case study describing an Internet Protocol (IP) version 6 (v6) introduction to an IPv4 Internet Service Provider (ISP) network infrastructure. The case study driver is an ISP willing to introduce a new “killer” service related to Internet of Things (IoT) style building automation. The provider and cooperation of third party companies specialized in building automation will provide the service. The ISP has to deliver the network access layer and to accommodate the building automation solution traffic throughout its network infrastructure. The third party companies are system integrators and building automation solution vendors. IPv6 is suitable for such solutions due to the following reasons. The operator can’t accommodate large number of IPv4 embedded devices in its current network due to the lack of address space and the fact that many of those will need clear 2 way IP communication channel. The Authors propose a strategy for IPv6 introduction into operator infrastructure based on the current network architecture present service portfolio and several transition mechanisms. The strategy has been applied in laboratory with setup close enough to the current operator’s network. The criterion for a successful experiment is full two-way IPv6 application layer connectivity between the IPv6 server and the IPv6 Internet of Things (IoT) cloud

Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths Status of This Memo

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards " (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust’s Legal Provisions Relating to IETF Documents in effect on the date of publication of this documen

Guifi.net: characterization, data collection and selfmanagement of community

In this project, we are going to present an E2E (end to end) solution for the principal problems that normally impact the community networks and especially Guifinet. To introduce our solution, we were investigating how the Guifinet works internally (its network hierarchy, equipment used, IP configuration and also its financial system) and also how wireless technology works and their limitations. Once we analysed and detected all the potential issues, we performed a routing performance and QoS (quality or service) simulation in order to test two experimental protocol called BATMAN and OLSR to find the most suitable routing protocol for our approach. And finally, we presented our new Guifinet network concept basing in MPLS over OLSR

On Compact Routing for the Internet

While there exist compact routing schemes designed for grids, trees, and Internet-like topologies that offer routing tables of sizes that scale logarithmically with the network size, we demonstrate in this paper that in view of recent results in compact routing research, such logarithmic scaling on Internet-like topologies is fundamentally impossible in the presence of topology dynamics or topology-independent (flat) addressing. We use analytic arguments to show that the number of routing control messages per topology change cannot scale better than linearly on Internet-like topologies. We also employ simulations to confirm that logarithmic routing table size scaling gets broken by topology-independent addressing, a cornerstone of popular locator-identifier split proposals aiming at improving routing scaling in the presence of network topology dynamics or host mobility. These pessimistic findings lead us to the conclusion that a fundamental re-examination of assumptions behind routing models and abstractions is needed in order to find a routing architecture that would be able to scale ``indefinitely.''Comment: This is a significantly revised, journal version of cs/050802

IPv6: a new security challenge

Tese de mestrado em Segurança Informática, apresentada à Universidade de Lisboa, através da Faculdade de Ciências, 2011O Protocolo de Internet versão 6 (IPv6) foi desenvolvido com o intuito de resolver alguns dos problemas não endereçados pelo seu antecessor, o Protocolo de Internet versão 4 (IPv4), nomeadamente questões relacionadas com segurança e com o espaço de endereçamento disponível. São muitos os que na última década têm desenvolvido estudos sobre os investimentos necessários à sua adoção e sobre qual o momento certo para que o mesmo seja adotado por todos os players no mercado. Recentemente, o problema da extinção de endereçamentos públicos a ser disponibilizado pelas diversas Region Internet registry – RIRs - despertou o conjunto de entidades envolvidas para que se agilizasse o processo de migração do IPv4 para o IPv6. Ao contrário do IPv4, esta nova versão considera a segurança como um objetivo fundamental na sua implementação, nesse sentido é recomendado o uso do protocolo IPsec ao nível da camada de rede. No entanto, e devido à imaturidade do protocolo e à complexidade que este período de transição comporta, existem inúmeras implicações de segurança que devem ser consideradas neste período de migração. O objetivo principal deste trabalho é definir um conjunto de boas práticas no âmbito da segurança na implementação do IPv6 que possa ser utilizado pelos administradores de redes de dados e pelas equipas de segurança dos diversos players no mercado. Nesta fase de transição, é de todo útil e conveniente contribuir de forma eficiente na interpretação dos pontos fortes deste novo protocolo assim como nas vulnerabilidades a ele associadas.IPv6 was developed to address the exhaustion of IPv4 addresses, but has not yet seen global deployment. Recent trends are now finally changing this picture and IPv6 is expected to take off soon. Contrary to the original, this new version of the Internet Protocol has security as a design goal, for example with its mandatory support for network layer security. However, due to the immaturity of the protocol and the complexity of the transition period, there are several security implications that have to be considered when deploying IPv6. In this project, our goal is to define a set of best practices for IPv6 Security that could be used by IT staff and network administrators within an Internet Service Provider. To this end, an assessment of some of the available security techniques for IPv6 will be made by means of a set of laboratory experiments using real equipment from an Internet Service Provider in Portugal. As the transition for IPv6 seems inevitable this work can help ISPs in understanding the threats that exist in IPv6 networks and some of the prophylactic measures available, by offering recommendations to protect internal as well as customers’ networks